Re: simple question on namespaces.
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format