OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: XSchema Spec, Section 3, Draft 2 (Namespaces)

[ Lists Home | Date Index | Thread Index ]
  • From: "Simon St.Laurent" <SimonStL@classic.msn.com>
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 2 Jul 98 20:45:36 UT

Here's another go, trying to make everyone happy and cover my butt for the 
multiple interpretations I can derive from the current draft.  I took James 
Anderson's suggestion that both the PI and the element could be included as a 
reasonable way to cover all possibilities.  While I don't think the PI is 
necessary, I can read that into the namespaces spec if I try hard enough.  (I 
can read many possibilities into the spec.  This is fun!)

The main changes are the additional requirement of the PI, much more 
uncertainty in the language, and the requirement that PIs appear before any 
XSC:ElementDecl elements.  That means I'll have to change Section 2.0 as well, 
coming soon.

As always, the pretty version will be at http://www.purl.org/NET/XSchema/.

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer / Cookies

3.0 XSchema and Namespaces

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.

3.1 The XSchema Namespace

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.

3.2 Interaction with Other Namespaces

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?)>
<!ATTLIST XSC:Namespace
	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?

3.3 Note Regarding Namespace Usage

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:

1. The only part of a namespace declaration that genuinely identifies the 
namespace is the ns production. The src is for additional information, and the 
prefix only serves as a proxy for the full ns production. This has several 
implications, the simplest of which allows developers to create XSchemas using 
prefixes other than XSC by specifying a different prefix in the XSchema 
namespace declaration described in Section 3.1.

2. The URLs in a namespace declaration will not need to be retrieved. The 
XSchema namespace declaration uses a PURL (permanent URL) provided by the 
OCLC. (For details on PURLs, visit http://purl.org.) PURLs use redirection to 
maintain a permanent address for sites that may change address. While XSchema 
specification information may be stored at the location to which the PURL 
server redirects visitors, XSchema applications should not rely on any of that 
information being there.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS