XSchema uses namespaces for its own operations and also supports schemas that take advantage of namespace facilities. XSchema processors are responsible only for elements that use the XSchema namespace appropriate to the version of XSchema they are processing. (This namespace is identified with the prefix XSC: throughout this document; see 3.3 below for information about alternative prefiexes.) Information in other namespaces may be passed to other applications as the processor deems appropriate.
Please note: the information in this section is based on the 18 May 1998 "Namespaces in XML" Working Draft and is will change to maintain conformance with that specification. Some features in this section are redundant, and required at present to make certain the XSchemas will have a high likelihood of working in whatever namespace environment develops.
XSchemas created using XSchema 1.0 should include the following namespace declaration after the XML prolog but before the appearance of DTD information and the XSC:XSchema element. This namespace declaration identifies elements prefixed with XSC: as elements that should be processed by an XSchema processor and also identifies the version number of the XSchema specification used.
<?xml:namespace ns="http://www.purl.org/NET/XSchema/v1" prefix="XSC"?>
This declaration is required. XSchema processors must always check for this declaration to properly recognize the prefix that will identify XSchema elements.
XSchemas will often support document sets that have their own namespaces. Because prefixes may change from document to document, and to provide the simplest possible solution, XSchema provides a mechanism for declaring namespaces within XSchemas. This allows documents and the XSchemas used to verify them to track the same namespace using different prefixes if necessary.
<!ELEMENT XSC:Namespace (Doc?)>
prefix CDATA #REQUIRED
ns CDATA #REQUIRED
src CDATA #IMPLIED>
The XSC:Namespace element and its contents are very similar to the <?xml:namespace?> processing instruction. The attributes of the XSC:Namespace element correspond to the prefix, ns, and src productions in the Namespaces Working Draft. The ns attribute for the namespace element is the most important part, containing a unique identifier that will be used to link the elements declared in an XSchema to their counterparts in the document. The ns attribute will contain a URI, typically a URL. (Note that #-separated identifiers are prohibited in the namespaces draft.) The src attribute can supplement the ns attribute if the unique identifier provided is not a URL but needs (perhaps) to be retrieved. The prefix attribute provides an identifier prefix that will be used throughout the XSchema to identify elements belonging to this particular namespace.
The ns attribute contains the key value that will be used to map XSchema element declarations to elements instance appearing in documents. So long as the ns attributes underlying the (possibly different) prefixes used in the XSchema and the document are the same, the mapping should work correctly. If namespaces are used which have different ns names, the mapping will be broken and the processor should report errors.
All XSC:Namespace elements within an XSchema must appear before the first XSC:ElementDecl element.
For interoperability with some interpretations of the Namespaces specification, XSchema documents must also be prefixed with namespace processing instructions that reflect the information contained in their XSC:Namespace elements. It is unclear at this point what processing model parsers will use to resolve namespaces, at what point in processing that resolution should take place, and what components of an XML document will have namespace prefixes resolved by the parser.
*** - Should namespace declarations in a parent XSC:XSchema element hold in XSC:XSchema subelements, or should they start over?
Namespaces are still in development at this time, and as such are subject to dramatic change.
This specification was written making several assumptions, which may or may not prove to be true as the Namespaces draft evolves: