Changes between Version 17 and Version 18 of CMDI 1.2/Schema sanity/Namespaces

Timestamp:

03/25/14 13:57:55 (11 years ago)

Author:

Menzo Windhouwer

Comment:

--

CMDI 1.2/Schema sanity/Namespaces

@@ -580 +580 @@
  * 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.
 
-
-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:
+To avoid these problems at least the fifth solution, i.e., profile specific namespaces, would be needed. Solution six, profile and component specific namespaces, raises the complexity of namespaces too much. Solution five actually uses components like [[http://docstore.mik.ua/orelly/xml/schema/ch10_10.htm|chameleon schema modules]] are used in in XSD, i.e., the imported elements are absorbed in the namespace of the importing schema. The drawback is that the fact that the same element is used by different vocabularies is lost. However, the CMD Infrastructure has its own solutions for that:
+
+1. The root elements of the components and profiles have a fixed, but optional,!ComponentId attributes allowing to identify shared components;
+2. All levels in a CMD record can be associated with a !ConceptLink, which can even indicate shared semantics between various components.
+
+The cleanest solution to avoid these problems it thus 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:
  * ignore Namespaces in XPath:
    * in XPath 1.0: `*[local-name()='ToolService’]`