xml-dev - Re: simple question on namespaces.

[Arjun Ray <aray@q2.net>]

On Thu, 28 Dec 2000, Uche Ogbuji wrote:

> The point is: what happens when the real tools that real people
> use begin to apply semantics to namespaces in conflicting ways.

Indeed.

> Paul is not the first to point out the essential contradiction of
> the Namespace WG in saying that namespaces are opaque, meaningless
> strings in one breath and then saying that they are URIs in the
> next.

IOW, there is an important practical distinction between '404 Not
Found' and 'Unsupported scheme'.

> Once you get over it, a bigger problem comes about since the
> choice of URIs as a territorial device effectively nullifies the
> hand-waving claims of "no semantics for namespaces". [...] The
> issue was somewhat dormant while there was really nothing to
> expect at the end of namespaces.  [...] However, now we have
> XSchemas, and there is a sizable body of conventional wisdom that
> suggests having an XSD at the business end of a namespace URI. I'm
> not sure where this CW comes from, but I have heard and read it
> often.

It seems that W3C luminaries had been "thinking along those lines" all
along, never mind that some 1500-2000 messages in the w3c-xml-sig
list can now be classified as an utter waste of time arguing over a
foregone political conclusion. 

> I don't want to claim I could make a better choice than the
> namespaces WG. [...] Nevertheless, I think it turns out that the
> semantics of namespaces are going to be a wild-card for
> interoperability and automation.

From my notes, I see that in July 1998 a co-editor of the XML-Names
spec wrote:

| I do not expect that a namespaces NSDef can be dereferenced to
| obtain a schema.  If a schema is associated with a namespace, 
| there will need to be some new mechanism invented for the 
| association: SRC was dropped.  The immediate use I see namespaces
| put to is recognition:  Programs can test names to see whether 
| they match a specific namespace and local name, thereby
| distinguishing names that would be otherwise conflictingly
| ambiguous.  [...] I definitely expect that many namespaces will 
| have associated schemas, and that this will be important.  I do 
| not, however, think that a namespace and an associated schema are
| identical.

Whereupon, a SIG member posted:

: Then I'm assuming you'd have no problem with explicitly prohibiting
: NSDef from being used to attach any sort of nonstandard document
: processing to the document? That *until there is a new mechanism*,
: we prohibit such abuses as *will* occur without such a prohibition? 
: I see no reason not to make this minor change to the draft.
:
: I've now repeated this question numerous times in numerous ways,
: with no reply. I think that if it is answered in the affirmative we
: can move forward given that the namespace draft can then *only*
: provide the functionality that I keep hearing is its sole raison
: d'etre. If not, I will continue to believe that a 'nudge nudge wink
: wink' hidden agenda exists, since the concept of associating some
: sort of ambiguous processing via NSDef continues to be discussed by
: supporters of the draft.

The co-editor responded by quoting the entire message in toto (TOFU
seems to the new style these days) and prepending one line at the top:

| I don't know precisely what that would mean.

The SIG member obliged with:

: > I don't know precisely what that would mean.
:
: Prohibiting NSDef from being dereferenced to an external document 
: would explicitly disallow it from being used to validate or attach
: processing to the document. I believe the latter will lead to wide 
: abuse. [...] 
: 
: >> I do not expect that a namespaces NSDef can be dereferenced to 
: >> obtain a schema.  If a schema is associated with a namespace, 
: >> there will need to be some new mechanism invented for the 
: >> association: SRC was dropped. 
: 
: If you are being honest here then there is no need to allow NSDef to 
: be resolved. I am asking that resolution be *explicitly prohibited*. 
: Otherwise we leave the door open for vendors to attach processing or 
: validation to the document via NSDef, a purpose you have stated it 
: is not to serve. 
: [...] 
: I'll ask it again:
:
:  Q: If namespaces are merely to disambiguate (ie., qualify) a
:     'namespace' prefix, the purpose of NSDef is merely to provide a
:     unique and controlled opaque string that identifies the
:     namespace. No less, no more. If this, as stated in the draft, 
:     is actually the case, then there is no need to resolve NSDef's
:     URI to an external document. To do so in an ambiguous,
:     unspecified way is to do irreparable damage to interoperability. 
:     I am asking that the draft be amended to explicitly prohibit 
:     NSDef from pointing to an external document that might be used
:     to validate an element type name against a vocabulary until such
:     time as both a resolution mechanism and a standardized protocol
:     for specifying such a vocabulary exists. 
: 
: or in short:
:
:  Q: Do you intend that namespaces be used to attach processing or
:     allow validation against an external vocabulary (or 'schema') 
:     pointed to by NSDef? 
: 
: You seem to have answered the latter already in the affirmative. I 
: take both to be the same question.


Suffice it to say, the requested prohibition never made it into the
XML-Names spec.

Nudge.  Nudge.  Wink.  Wink.

> All sides certainly have enough ammo to bring to aWar over
> Namespace Semantics.  Why should we not engage?

Because nothing new has been said in all this time?  Might it not be
better to call for the w3c-xml-sig archive to be opened?  

Nah, never mind.


Arjun