Transformation of CCSL into a CMD profile schema definition
A CMD instance document that is serialised as XML according this specification SHOULD contain a reference the location of a CMD profile schema. The infrastructure MUST provide a mechanism to derive such a schema for any specific CMD profile on basis of its definition and that of the CMD components that it references. This section specifies how different aspects of a CMD specification should be transformed into elements of a schema definition. The primary schema language targeted is XML Schema, although the infrastructure MAY provide support for other schema languages, such as DDML or Relax NG.
CMD profile schemas SHOULD NOT (MUST NOT?) be derived from CMD specifications that are not CMD profiles.
The transformation as described here is assumed to take place on the fully expanded CMD profile, i.e. a version of the specification that has all referenced (non-inline) CMD Component definitions are resolved and substituted, recursively, by their full definitions.
General properties of the CMD profile schema definition
A CMD profile schema MUST be a single document {or set of linked documents with a single entry point}(?) that allows for the evaluation of a CMD instance on all levels of description defined in one specific CMD profile.
The schema MUST require the presence of a CMD instance envelope as described in section "Structure of CMDI-files". The value of the <MdProfile> header item in the CMD instance envelope MUST only be valid if it is equal to the profile id as specified in the associated CMD profile.
The CMD profile schema SHOULD include, as a matter of annotation, a copy of (a subset of) the information contained in the Header section of the CMD profile from which it is derived.
The transformation MAY make use of embedded component identifiers in the CMD component definition to derive (complex) types that can be reused throughout the schema definition.
Interpretation of CMD component definitions in the CCSL
CMD Components which are represented as <Component> XML elements in the CCSL, MUST be realised as XML element declarations with the following property mapping:
| Property | XML schema attribute | Derived from | Use |
|---|---|---|---|
| Name of the XML element | @name | @name | REQUIRED
|
| Minimal number of occurrences | @minOccurs | @CardinalityMin, or '1' if XML attribute not present | REQUIRED 1
|
| Maximal number of occurrences | @maxOccurs | @CardinalityMax, or '1' if XML attribute not present | REQUIRED 1
|
| Concept link | @dcr:datcat | @ConceptLink | OPTIONAL
|
| Component id | @cmd:ComponentId | @ComponentId | OPTIONAL
|
1The implementation may make use of default evaluation of the schema language if it matches these requirements, as is the case with XML Schema, and therefore omit explicit declaration of these properties
An optional XML Attribute @cmd:ref of type xs:IDREFS MUST be allowed on the XML container element derived from any CMD component.
<Documentation> XML elements contained in CMD Components SHOULD be transformed into documentation elements embedded in the XML element declaration. In these, the content language information contained in the @xml:lang XML attribute SHOULD be preserved.
XML attributes of CMD Components in the 'cue' namespace SHOULD be copied into the XML element declaration, in which case the XML attribute name, namespace and value SHOULD be preserved.
Document structure prescribed by the schema
The first CMD component defined in the CMD profile (the "root component") MUST be mapped as the mandatory, only direct descendant of the <Components> XML element of the CMD instance envelope.
CMD components that are defined as direct descendants of another CMD component MUST be mapped as direct descendants of the XML element declaration to which it is transformed. XML components at the CMD component level in the metadata instance MUST be required to be included in the same order as defined in the CMD specification, the first of the resulting XML elements appearing after the last XML element derived from a CMD element at the same level, if present. These descendant CMD Components MUST also be mapped to XML element declarations recursively as described in this specification.
CMD elements MUST be mapped as direct descendants of the XML element declaration derived from the CMD component of which they are direct descendants, and MUST be required to be included in the same order as defined in the CMD specification.
CMD attributes that are defined in the CCSL within "Attribute" XML elements within an "AttributeList?" XML element that is a direct descendant of a CMD Component MUST be mapped to XML attribute definitions on the XML container element to which it is transformed.
Interpretation of CMD element definitions in the CCSL
CMD elements, represented as <Element> XML elements in the CCSL, MUST be realised as XML element declarations with the following property mapping:
| Property | XML schema attribute | Derived from | Use |
|---|---|---|---|
| Name of the XML element | @name | @name | REQUIRED
|
| Minimal number of occurrences | @minOccurs | @CardinalityMin unless @Multilingual is true,in which case MUST be 'unbounded', or '1' if neither XML attribute is present | REQUIRED 1
|
| Maximal number of occurrences | @maxOccurs | @CardinalityMax, or '1' if XML attribute not present | REQUIRED 1
|
| Type of the XML element | @type | See section 'Content model' | |
| Concept link | @dcr:datcat | @ConceptLink | OPTIONAL
|
| Auto value instruction | @cmd:AutoValue | @AutoValue | OPTIONAL
|
1The implementation may make use of default evaluation of the schema language if it matches these requirements, as is the case with XML Schema, and therefore omit explicit declaration of these properties
<Documentation> XML elements contained in CMD elements SHOULD be transformed into documentation elements embedded in the XML element declaration In these, the content language information contained in the @xml:lang XML attribute SHOULD be preserved.
XML attributes of CMD Elements in the 'cue' namespace SHOULD be copied into the XML element declaration, in which case the XML attribute name, namespace and value SHOULD be preserved.
An optional XML Attribute @cmd:ValueConceptLink of type xs:anyURI MUST be allowed on the XML element derived from a CMD element that has a vocabulary with XML attribute @URI defined (see section "Content model for CMD elements and CMD attributes in the schema definition").
The derivation of a content model for the XML element declaration on basis of a CMD element is described below.
Interpretation of CMD attribute definitions in the CCSL
CMD attributes, represented as <Attribute> XML elements in the CCSL, MUST be realised as XML attribute declarations with the following property mapping:
| Property | XML schema attribute | Derived from | Use |
|---|---|---|---|
| Name of the XML element | @name | @name | REQUIRED
|
| Use of the XML attribute | @use | 'required' if and only if @Required is present and equals true, otherwise 'optional' | REQUIRED 1
|
| Type of the XML attribute | @type | See section 'Content model' | |
| Concept link | @dcr:datcat | @ConceptLink | OPTIONAL
|
| Auto value instruction | @cmd:AutoValue | @AutoValue | OPTIONAL
|
1The implementation may make use of default evaluation of the schema language if it matches these requirements, as is the case with XML Schema, and therefore omit explicit declaration of these properties
<Documentation> XML elements contained in CMD attributes SHOULD be transformed into documentation elements embedded in the XML attribute declaration In these, the content language information contained in the @xml:lang XML attribute SHOULD be preserved.
XML attributes of CMD Attributes in the 'cue' namespace SHOULD be copied into the XML attribute declaration, in which case the XML attribute name, namespace and value SHOULD be preserved.
The derivation of a content model for the XML attribute declaration on basis of a CMD attribute is described below.
Content model for CMD elements and CMD attributes in the schema definition
If a CMD element or CMD attribute in the CCSL has a @ValueScheme XML attribute, its value MUST be interpreted as the name of the XML Schema Datatype (declared in the @type attribute of the XML element or attribute declaration in XML Schema) that defines the allowed value range of the XML element/attribute derived from the CMD element/attribute.
Otherwise, if a CMD element or CMD attribute in the CCSL has a descendant XML element <ValueScheme> that contains an XML element <pattern>, then its text value MUST be interpreted as the XML Schema Regular Expressions that defines the allowed value range of the XML element/attribute derived from this CMD element/attribute.
Otherwise, if a CMD element or CMD attribute in the CCSL has a descendant XML element <ValueScheme> that contains an XML element <Vocabulary>:
- The XML attribute
@URIof the XML element<Vocabulary>, if present,SHOULDbe transformed into an attributecmd:Vocabulary1 of the same value on the XML element or attribute declaration in the schema. - The XML attributes
@ValuePropertyand@ValueLanguageof the XML element<Vocabulary>SHOULDbe transformed into XML attributes1 in the 'cmd:' namespace on the XML element declaration in the case of a CMD element or XML attribute declaration in the case of a CMD attribute. - The XML elements
<item>that are descendants of<enumeration>contained in<Vocabulary>MUSTbe transformed into an enumeration based restriction with values taken from the text content of the<item>XML elements. Each enumeration item in the schemaSHOULDbe annotated the value from the XML attribute@ConceptLinkby means of an XML attribute@dcr:datcat1 and the value of the XML attribute@AppInfoby means of an attribute in the 'ann' namespace.
1The attributes @cmd:Vocabulary, @cmd:ValueProperty, @cmd:ValueLanguage and @dcr:datcat should be present in the schema, not be declared as attributes allowed in the CMD instance
