Lists Home |
Date Index |
- From: Arjun Ray <email@example.com>
- To: firstname.lastname@example.org
- Date: Thu, 28 Dec 2000 18:50:49 -0500 (EST)
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.
> 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
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
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
| 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
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
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.