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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: URIs and information typing

At 04:48 PM 3/8/01 +0000, Henry S. Thompson wrote:
>If I've understood you correctly, this changes both the syntax _and_
>the architectural underpinning of type naming, and schema component
>referencing in general.

Yes, in directions which I think make XML Schema far easier to stomach in a 
world where more than one schema language may well exist and be in use.

>I'm not sure either aspect of this move is a
>good idea, for at least two reasons:
>1) If it ain't broke, don't fix it -- I'm no knee-jerk fan of
>terseness, but requiring fully explicitly qualified names everywhere
>you need to reference one component from another in a schema would be
>a _substantial_ burden on schema authors _and_ schema readers.

As I pointed out in the previous message, I do consider the current 
mechanism 'broke'.  References inside schemas to types aren't much harder - 
they may even become easier if you just reference "#myType" instead of 

>1) It would _require_ dereferencing namespace URIs, something we've
>strenuously avoided in the design to date, for a range of reasons
>including, but not limited to:
>   1a) It would require connectivity or transparent offline-caching;
>   1b) It would introduce network latency as a dominating factor in
>       efficiency;
>   1c) It removes existing flexibility about what is found at the end
>       of namespace URIs -- it's _really_ not up to XML Schema to
>       settle this question.

No.  My proposal doesn't require deferencing namespace URIs, unless a 
processor had to deal with the original RDDL problem of finding out 
information about a document.

It _could_ require deferencing the URIs used to identify types. I don't 
think that problem is any more severe than the other mechanisms already 
inside of XML Schema which rely on URI resolution.

>2) It would remove what many of us feel is an important flexibility in
>the design of XML Schema, namely that top-level element, attributes,
>types and identity constraints are in separate 'symbol spaces', that
>is, it's OK to have all of a top-level element, a top-level attribute
>and a type with the same name, something your proposal would rule out.

Uh, well, your flexibility frequently proves to be my inflexibility.  The 
'separate symbol spaces' look to me like an odd mess of different things 
sharing very similar-looking syntax.  Namespace prefixes on 
types?  Really?  That's pretty weird, when you think about what Namespaces 
in XML defines.

All my proposal does is make you use URIs rather than QNames for 
_types_.  That appears to enforce a more thorough separation...

Also, though it's probably too late, you might want to have a look at 
RELAX.  It's pretty good about the separation between a thing's role and 
its label, which IMHO does a better job of solving the problem you're 
describing above.

Simon St.Laurent - Associate Editor, O'Reilly and Associates
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books