Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
|||||||||
