XSchema Spec, Section 3, Draft 1 (Namespaces)

[Ron Bourret]

OK.  I finally sat down and read this discussion from start to finish.  I can 
safely say that my head hurts.  In reading the following, please remember that 
my parser skills are at the duct tape (that's gaffer tape to you Brits) and 
baling wire level, so please be gentle with my (mis)use of terminology.

Summary of the Current Situation
================================

1) When we talk about resolving and encoding/decoding, we're talking about the 
part of the software that says, "Ooo.  Let's see.  This prefix matches with 
that, and those prefixes matches with these, and...add a bit of newt's wing... 
ah-hah!  This is the Foo element in the Bar namespace!"  This results in a 
token/unique identifier, which tells the rest of the software what to do (if 
token==ORDERPIZZA... else if token==DRINKCOKE... else if...)

2) Namespaces appear in three places in XSchema documents:
a) Identifying XSchema elements (ElementDecl, AttDef, etc.)
b) Identifying elements under the More element
c) Identifying elements being described by the XSchema (qualified names occur in 
attributes of ElementDecl, AttDef, and Ref)

3) Currently, cases (a) and (b) use namespace PIs; case (c) uses a Namespace 
element.  XSchema processors pay attention to case (b) only if they know about 
those elements.

4) The discussion is about whether to use Namespace elements or not.  As far as 
I can tell, the main arguments are as follows:

PRO: The Namespace element makes it easier to distinguish case (c).  It adds 
documentation to namespaces.  It follows the XSchema-uses-elements philosophy.

CON: The namespace PI is the standard way of declaring namespaces.

What is important to me is that, with the possible exception of documentation, 
none of these arguments state that something is possible with one method that is 
not possible with the other.

My Two Cents
============
Here are my thoughts on the subject.

1) I'm currently implementing this code and find the difference between the two 
methods to be negligible.  I get a slight efficiency with the Namespace element 
because I can distinguish between (b) and (c).  Note that I am building a SAX 
application and the parser doesn't do anything for me namespace/resolution-wise. 
 The call to startElement returns a prefix-qualified name that I must resolve.

2) If we keep the Namespace element, it is possible for an XSchema document to 
use the same prefix for two different namespaces -- once in either (a) or (b), 
and once in (c).  My resolver needs to be aware of this.

3) I am not convinced that Namespace elements are going to work when we XLink 
XSchemas together.  From james' mail, I gather that generic software for 
traversing XLinks will probably issue namespace PIs to the calling (XSchema) 
application.  This enables the calling application's resolver to resolve any 
prefixes it receives.  Generic XLink software would certainly not return 
Namespace elements.  For XSchema, this means that the user must create separate 
XLinks to the relevant Namespace element(s) (yech), or the programmer must write 
XSchema-aware software for traversing XLinks (double-yech).

If (3) is true, it is a convincing case (in my mind) for using PIs.

If it is not true, and generic XLink resolvers somehow really do hand me back a 
token that is meaningful to me, then I'm happy for Simon to flip a coin, put his 
foot down, or anything else that makes him happy.

I need an aspirin.

-- Ron Bourret

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