- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 03 Jul 2002 11:04:28 +0300
- To: ext Tim Bray <tbray@textuality.com>, WWW TAG <www-tag@w3.org>
On 2002-07-03 0:47, "ext Tim Bray" <tbray@textuality.com> wrote: > > Bullard, Claude L (Len) wrote: > >>> I stand by my concerns in regards anybody who has high-value reference >>> information which would increase the usability of their offering and >>> declines to make it part of webspace. >> >> You do not deal with high security information or systems that must >> produce and maintain it, or policies that govern such systesm. >> You are not competent to make that call. > > In fact I have done business both with Fort Meade and the OSD and I > understand something of those issues. If you send me XML to process, > and you put that XML in a namespace, and you give the namespace a name > that makes it impossible for me to dereference it to help figure out > your data, I'm going to be annoyed. Even if it only says something like > "The contents of elements in this namespace are encrypted and must be > maintained in canonical form" or "For more information about this data > call (703) 482-0623 and ask for Ernie" that is much better than nothing. > We're trying to write rules for data that's out there on the Web. -Tim Well, what if (a) the namespace name is an http: URL and (b) there actually is a namespace document accessible at that URL but (c) that URL is behind a firewall and not publically accessible, since, after all, this is sensitive material. That's not going to do you any more good than not having a dereferencable namespace URI to begin with. (Yes, some folks may argue that if it's behind a firewall it's not "on the web" but I don't hold that view -- accessibility can be affected by all sorts of conditions, and I doubt that anyone would say that some web page that is password protected but publically and globally accessible otherwise is not "on the web") The real problem is that namespace names and namespace documents are insufficient to do what folks want them to do. This is because XML and other web documents do not actually specify the particular document model to which they conform, and thus one has no real means to know for certain, given a particular XML instance, what constraints or interpretations apply. Take XHTML as an example. There is one single namespace URI, but three functional vocabularies and three document models, and the structural and semantic definitions of some terms differ between the different document models. It is impossible to know, based on the identity of the root element term, which document model applies, and even if each document model has associated with it various schemas via some namespace document, you don't know which schema the instance must conform to. C.f. http://lists.w3.org/Archives/Public/www-tag/2002Feb/0137.html A namespace name does not identify a single vocabulary, or a single document model, or a single schema, etc. There can be multiple vocabularies all sharing terms ground in the same namespace, and there can be multiple document models using terms from the same vocabularies, and of course, there can be multiple schemas of various languages/encodings defining those terms, vocabularies, and document models. So neither an application or a human getting some XML instance is *not* going to be able to figure out from that instance itself which document model, which vocabulary, which schema, etc. applies. Much of the intended benefit of namespace documents retrievable from namespace name URLs is an illusion. It's wishful thinking that the currently deployed web architecture does not provide for, and changes to the architecture to ensure such behavior would be IMO far too drastic, even for the TAG to make. Yes, we need a consistent, standardized way to obtain information about terms, vocabularies, document models, schemas, etc. -- really about any resource whatsoever -- but overloading namespace names to serve as the mechanism for providing that information is IMO a short sighted hack that won't work generically for the complete scope of the *currently* defined and deployed web. There is a fundamental problem with the current web architecture in that it does not make any distinction between a representation of a web-accessible resource and information *about* a resource, whether it is web-accessible or not. A term in some vocabulary is an abstract resource, and if the URI denoting that term dereferences to anything, then that is a bug, since it is impossible to actually obtain a representation of an abstract resource. Similarly, a namespace is an abstract resource, and thus, if a URL is used for the namespace name, having it resolve to anything is IMO a bug, just as for any abstract resource. One solution to this problem would be to extend HTTP to provide support for the retrieval of information about resources as well as web-accessible resources themselves. C.f. http://lists.w3.org/Archives/Public/www-talk/2002MayJun/0039.html In this fashion, one may describe any resource whatsoever, even a namespace, without requiring that the URI used to denote that resource resolve to anything, and use HTTP to execute queries about particular resources, such as namespace names. I consider this to be a much better solution, which does not blur the distinction between resource and information about a resource -- as the present proposal of dereferencable namespace URIs does. Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com
Received on Wednesday, 3 July 2002 04:04:27 UTC