Constraint Format

1 Introduction

…

1.1 Overview

A Constraint Pattern is an abstract definition of a function that gets a set of parameters and a document as input and returns an analysis result report
A Data Model is a set of documented elements from a specific data format
A Constraint is a reference to a constraint pattern with all parameters set to specific values
A Constraint Template is a reference to a constraint with optional parameter values and a sentence where part of the sentence are mapped to parameters
An Analysis Result lists elements of a document together with references to constraints and whether their conditions have been met in the document

1.2 Conformance requirements

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals, as shown here.

2 Data Model

A Data Model is a JSON object with:

id - identifier of the model
title - title of the model
format - the underlying base format (xml, json, rdf, csv, pica… this list needs to be defiend)
elements - a set of elements, given as JSON array. Each element is a JSON object with:
- path - machine-processable location of the element. Syntax and semantics depends on the format, for instance format xml implies XPath syntax
- label - human-readable label, tagged by language code for multilinguality

Data models can often be derived from schema files (XML Schema, JSON Schema, Avram Schema…) by extraction of elements and labels.

Example:

{
  "id": "lido-1.1",
  "title": "LIDO 1.1",
  "format": "xml",
  "elements": [
    {
      "path": "//lido/administrativeMetadata/resourceWrap/resourceSet/resourceRepresentation",
      "label": { "en": "Resource Representation" }
    },
    {
      "path": "//@*[name()='lido-type']",
      "label": { "en": "Type" }
    }
  ]
}

3 Constraint Pattern

An Constraint Pattern (or Pattern) is a JSON object with:

id - identifier of the pattern
description - human-readble description (English)
parameters - parameters of the pattern, given as JSON object mapping parameter name to parameter definition. Each parameter definition is a JSON Objects with
- type - the data type. One of path, number, comparator, list… (this needs to be defined)

Example:

{
  "id": "MandAtt",
  "description": "Checks that an element contains another element",
  "parameters": {
    "elem" : { "type": "path" },
    "prop": { "type": "path" }
  }
}

4 Constraint

A Constraint is a JSON object with:

id …
format …
model …
pattern REQUIRED …
fragments OPTIONAL, only meant for communication with humans. MUST be ignored for execution/analysis!
parameters parameter values. If fragments is given, parameters MUST be derived automatically from fragments for consistency

Property names MUST match parameter names of the referenced pattern

Example:

{
  "id": "Q04.8a",
  "format": "xml",
  "model": "lido-1.1",
  "title": "Resource Representation Has Required Type",
  "pattern": "MandAtt",
  "fragments": [
    { "text": "Each" },
    { 
      "parameter": "elem", 
      "value": "//lido/administrativeMetadata/resourceWrap/resourceSet/resourceRepresentation"
    },
    { "text": "has a" },
    {
      "parameter": "prop",
      "value": "//@*[name()='lido-type']"
    },
    { "text": "." }
  ],
  "parameter": {
     "elem": "//lido/administrativeMetadata/resourceWrap/resourceSet/resourceRepresentation",
     "prop": "//@*[name()='lido-type']"
  },
  "keywords": [ "DDB" ]
}

Example (minimal form for checking/execution/analysis):

{
  "pattern": "MandAtt",
  "format": "xml",
  "parameters": {
     "elem": "//lido/administrativeMetadata/resourceWrap/resourceSet/resourceRepresentation",
     "prop": "//@*[name()='lido-type']"
  }
}

5 Constraint Template

A Constraint Template (or Template) is a Constraint with some or all parameters not set.

…

Example:

{
  "pattern": "MandAtt",
  "fragments": [
    { "text": "Each" },
    { "parameter": "elem" },
    { "text": "has a" },
    { "parameter": "prop" },
    { "text": "." }
  ]
}

6 Analysis Result

The analysis result format is based on Validation Error Format.

7 References

7.1 Normative References

Berners-Lee, T. and Fielding, R. and Masinter, L.: Uniform Resource Identifier (URI): Generic Syntax. RFC 3986, January 2005, http://www.rfc-editor.org/info/rfc3986.
Bradner, S.: Key words for use in RFCs to Indicate Requirement Levels. BCP 14, RFC 2119, March 1997, http://www.rfc-editor.org/info/rfc2119.
Bray, T.: The JavaScript Object Notation (JSON) Data Interchange Format. RFC 8259, December 2017. https://tools.ietf.org/html/rfc8259

Voß, J: Validation Error Format. May 2026 https://gbv.github.io/validation-error-format/

7.2 Informative references

…

Appendices

JSON Schemas

Constraint, Constraint Patterns and Constraint Templates can be validated each with one of the following non-normative JSON Schemas:

…