Re: XML Schema built-in data type namespace URI

[Charles Reitzel <creitzel@mediaone.net>]

Sorry to jump in late in the thread.  I have responses to a few of the issues raised.

First, there is something much, much simpler that can be done to resolve the inconsistency between XML Schema "Structures" and "Datatypes". Just fix up Structures to acknowledge the DatatTypes NS when referring to built-in types.  They shouldn't both claim it.  This is a -minor- bug in Structures.

I think there are a couple places in the text where this could easily be fixed.

Section 2.6, http://www.w3.org/TR/xmlschema-1/#concepts-nameSymbolSpaces, should say something like [my additions]:

"[Except for built-in datatypes, ]The XML representation of schema components uses a vocabulary identified by the namespace URI http://www.w3.org/2000/10/XMLSchema. [Built-in data types use the http://www.w3.org/2000/10/XMLSchema-datatypes namespace URI.]"

Section 4.1 (XML Representation), discusses the issue as well without acknowledging the overlapping NS URIs.  Instead it should just explain and *use* the Datatypes NS URI for built-in types.

==============================================================

-1 for requiring every Schema type, group, attribute and element to have its own NS URI.  RDF goes too far in this direction for my taste.  While a good idea for W3C or other widely shared specs, it's probably overkill for most user schemas.  A QName, per the XML Namespaces spec, is plenty unique, thank you.

==============================================================

Using the ID attribute would probably assist in looking up type information when processing instance docs.  I.e. try the direct approach and, if you don't get a hit, do a more complex XPointer search in the Schema.  Ditto for type mismatches: you get a type when you were looking for an element, etc.  If a schema doesn't define any IDs, then the overhead of checking is negligble.  If it does, it will probably pay off.  Such use of IDs is totally under the schema designer's control.  The same logic might work for linking data in any two XML documents, right?

==============================================================
Sorry, but I need to wax philosophical:

It may look like I'm falling into the "Just the syntax, ma'am" camp.  I'm not sure I'd want to limit things to that, but if you get the syntax clean, the object models follow much more easily.  

I don't want give up either SAX or DOM.  Typically, one is layered over the other.  Sometimes you need to get closer to the metal.  Sometimes you need a buffer layer.

Nor am I shopping for any brand new processing models or APIs.  I'd much rather see conservative extensions to the existing stuff.  Do we need an Infoset API?  I doubt it. I'm not sure why the Infoset isn't defined as an XML-only subset of the DOM.  (I.e. what can you rely on to be in a DOM when you load it with an XML document.  What are the options?)  Nor do I think SAX can or should be construed as an Infoset.  It is possible to construct one from SAX events, but SAX will just as likely drop all your data on the floor (which is a good thing).

take it easy,
Charles Reitzel


At 03:10 PM 3/9/01 +0100, Eric van der Vlist wrote:
>"Henry S. Thompson" wrote:
>> 
>> To try to bring your and Simon's threads together, I 
>> think what we're struggling with is the difference 
>> between the concept "unsignedInt" as defined by the 
>> W3C XML Schema spec. and various representations and/or
>> manifestations of it, and then trying to generalise 
>> from this particular case to the general case of 
>> elements and attributes and types in any namespace.
>
>I think that we should not restrict this debate to buit-in datatypes: we also need to identify the users datatypes
>though URIs and have the same kind of issue.
>
>I can define a datatype through:
>
><xsd:simpleType name="myUnsignedInt" id="myUnsignedInt" ...
>
>However, XPointer applies here since a schema is a XML document and the URI associated with the simpleType element will be {current schema location}#myUnsignedInt where {current schema location} may or may not be equal to the target namespace (assuming there is one) and is not fixed (what if I copy this schema on my local file system).
>
>Furthermore, as you have highlighted it, duplicating names into ids would violate the principle of different "namespaces" for types, elements, attributes, ...
>
>I wonder if a simple solution|workaround wouldn't be to add (or replace the id) with an attribute which would define the full URI of the type:
>
><xsd:simpleType name="myUnsignedInt"
>uri="http://dyomedea.com/ns/types/myUnsignedInt" ...
>
>The designer of the schema would then have the responsibility, when he needs it, to define a URI using a scheme that he would fully control.


take it easy,
Charles Reitzel