| | 276 | |
| | 277 | ---- |
| | 278 | The goal of XML namespaces is to provide a clean partition the "name universe" for XML. The XML Namespace recommendation states: |
| | 279 | "We envision applications of Extensible Markup Language (XML) where a single XML document may contain elements and attributes (here referred to as a "markup vocabulary") that are defined for and used by multiple software modules. [..] Such documents, containing multiple markup vocabularies, pose problems of recognition and collision. Software modules need to be able to recognize the elements and attributes which they are designed to process, even in the face of "collisions" occurring when markup intended for some other software package uses the same element name or attribute name." [http://www.w3.org/TR/xml-names/#sec-intro Namespaces in XML 1.0, Section 1 "Motivation and Summary"] |
| | 280 | |
| | 281 | The overall approach of CMDI is to define a set of (metadata) components, that get compiled into profiles. Authors of components are free to choose the (inner) structure and the names for their components on their own. Two independent metadata authors can easily come up with Profiles, that contain components that uses the same name, but a different structure, i.e. one `Creator` component, that just has no further inner structure and another `Creator` component, that is further structured in `Name`, `Organization` and `Email`. |
| | 282 | |
| | 283 | The CMDI profiles will be compiled into XML schema documents and components become XML elements. In the current implementation, CMDI puts all XML elements into one ''generic CMDI XML namespace'', i.e. the two `Creator` elements are identified by the same QName. However, these two `Creator`s conceptually different things, cause they have a different structure and thus, their XML representation have conflicting content models. |
| | 284 | As long as XML instances created from these XML Schema are not used in together in one context, things work. But if used together, this is a recipe for problems. For example consider the following scenarios: |
| | 285 | * XML Parsers: an XML Parser parsing and validating a batch of CMDI instances from various profiles can cache an internal representation of a parsed XML schema based on XML Namespaces to speed up the processing. However, if it first caches an XML schema, that contains no "Creator" elements, it will reject all instances, that happen to contain "Creator"s. Or, if it caches the "flat" `Creator`, it will reject the structured `Creator`. \\ |
| | 286 | Tools that might use such a processing model are VLO, Metadata Assement Services or other repositories aggregating metadata from various sources. |
| | 287 | * XML Binding: frameworks to map from XML to Objects can fail on CMDI profiles, because all profiles are in the same XML namespace, thus a programs fail if they encounter CMDI instances from a different profile. |
| | 288 | * Using CMDI in other contexts, i.e. embedded in other protocols. One example is OAI-PMH. CLARIN requires centers to make their metadata available for harvesting by means of OAI-PMH. OAI-PMH required to link each metadataPrefix to an ''unique'' XML schema [http://www.openarchives.org/OAI/openarchivesprotocol.html#MetadataNamespaces Section "3.4 metadataPrefix and Metadata Schema"]: it defined "The XML namespace URI that is a global identifier of the metadata format" and "The metadata schema URL - the URL of an XML schema to test validity of metadata expressed according to the format". As long as centers only use one profile, they are fine. However, if their repository contains CMDI records from various profiles, it's harder to select an appropriate schema to announce via OAI-PMH. (NB: the only solution is to use the ''minimal'' CMDI XML schema, but very few centers currently do that. Furthermore, to also validate the structure below the `Components` elements, more has to be done) |
| | 289 | |
| | 290 | A clean solution to avoid these problems it to have a general CMDI XML namespace for the ''wrapper'' elements of an CMDI instance (Header, ...) and a profile specific namespace for the elements below the `Components` elements. The following approaches could be used to lessen the impact of this change for users who don't care for Namespaces: |
| | 291 | * ignore Namespaces in XPath: |
| | 292 | * in XPath 1.0: `*[local-name()='ToolService’]` |
| | 293 | * in XPath 2.0: `*:ToolService"` |
| | 294 | * use a "flattener XSLT": this stylesheet will put all elements into the same namespace (and deliberately breaking validation). Users can than use their traditional XPath expressions. However, "flattened" CMDI instances SHOULD only be transient contexts, i.e. they MUST NOT be used for long term storage or exchange. (Menzo has prepared such a style-sheet. Thanks!) |
