XSchema Spec, Section 3, Draft 1 (Namespaces)
rbourret at dvs1.informatik.tu-darmstadt.de
Thu Jul 2 20:25:35 BST 1998
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
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev