Version 6 (modified by 9 years ago) (diff) | ,
---|
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 MAY
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 MAY
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.
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.
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
|
Concept link | @dcr:datcat | @ConceptLink | 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 MAY
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.
The derivation of a content model for the XML element declaration on basis of a CMD element is described below.