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: Namespaces, schemas, Simon's filters.



Tim,

> -----Original Message-----
> From: Tim Bray [mailto:tbray@textuality.com]
> Sent: Friday, August 24, 2001 2:16 PM
> To: xml-dev@lists.xml.org
> Subject: RE: Namespaces, schemas, Simon's filters.
> 
> 
> It's difficult for Matt Fuchs and I to have a straightforward 
> discussion because there's some terminology getting in the 
> way: Matt calls elements which are in a namespace "global" and 
> those which aren't "local".  I suspect that he associates some 
> [schema-related?] semantics with the terms "local" and 
> "global".
> 

Uh, now I'm kinda confused.  I thought this was a discussion of XML Schema,
the distinction in it between elements of global scope and elements of local
scope[1], and how to use namespaces to represent local elements.  Of course
we can't have a straightforward discussion if you have a senior moment in
the middle and forget what we're talking about ;->   And I understand if
you're reluctant to read the Schema spec, but most people consider the
Primer [2] much easier to follow and it also explains the distinction.  

It's not that I want to drag in weird terminology and call namespaced
elements "global", it's that Schema unilaterally places all global elements
in the namespace of the defining schema.  However it works hard to allow the
Schema author to be as confusing as possible with with local elements.  I
don't call elements that are not in a namespace "local", I'm arguing that in
the current situation, namespaces are inadequate for distinguishing local
elements and therefore should be avoided until a good solution is found
rather than using a half-assed one.

> It kind of puzzles me, because as we saw here recently, a schema 
> can specify many different validation policies for elements of type 
> <myNS:x> depending on their context, just as any other software is 
> free to take the context into account in applying semantics to 
> markup.  So I can't see any sense in which the term "global" is 
> helpful.
> 

I find your argument here in strong contrast to your call for having
"everything unambiguously and completely labeled with minimal reliance on
context." [3] (and other posts I can't find right now because I'm offline.)
The same argument can be given against namespaces - why use namespaces, just
use context to figure out what element is being used.  "Global" and "local"
are terms from Schema.  In Schema, the different elements in the schema myNS
with name x have absolutely no a priori relationship to each other - they
don't have the same type.  Two local elements in a schema with the same
local name have no more relationship to each other than do two elements from
different namespaces - if a schema has complexTypes foo and bar, and each
has a local element x, those two x elements have no more in common than if
foo and bar were different namespaces, each with an element x.

> Put another way: whether or not an element is in a namespace is 
> orthogonal to whether its semantics are context-sensitive.  Given 
> this, why would one ever not use namespaces?
> 

Namespaces are just a mechanism - as you yourself have argued, they're a
mechanism for unambiguously distinguishing things.  Just, they don't express
the intentions of the schema author with regards to local elements (as
defined by Schema) and will confuse sofware.  I want to use namespaces for
local elements, but not in the current half-assed way.  If you reread my
last post in response to you, you'll see that I advocate fixing the current
situation, but keeping local elements out of a namespace is the most
forwards compatible way to do so.  If you take a look at the description of
NUNs in the XML Schema:  Formal Description document [4], you might see one
way of doing this.

> To conclude: I still claim that when you're inventing a markup 
> vocabulary, interoperability, robustness, and flexibility are 
> improved by placing all your elements in your namespace.  In 
> addition to the problems I pointed out before, Matt highlighted 
> another: if you qualify all your own elements, you can't get screwed
> up by other people's default-namespace declarations; elements that 
> are "local" in Matt's sense of the word obviously can be. -Tim 

Once again, read my lips - I agree with you.  However, knee-jerk advocacy of
namespacing everything, when that just keeps things broken, is not the way
to go.

Matthew

[1] http://www.w3.org/TR/xmlschema-1/#Declarations_Summary
[2] http://www.w3.org/TR/xmlschema-0/
[3] http://lists.xml.org/archives/xml-dev/200108/msg00952.html
[4] http://www.w3.org/TR/xmlschema-formal/