Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Just require URLs
 Didier PH Martin wrote: > interpretable documents. > c) If we choose to use a URL for a name space identifier, we create location > dependency to our documents, If we choose URNs, the documents are then > location independent. Again, with some forward thinking, the name space I would like to remind everyone that URLs are no more or less fragile or "location dependent" than URNs are. Both can be equally indirect. This is same as the bogus PUBLIC/SYSTEM distinction SGML makes: a pointer to a thing is a pointer to a thing, and the degree of indirection you expect to have behind it is both unknowable and irrelevant to the use of the pointer. Adding indirection within the data representation mechanism (e.g., entity resolution in SGML, URN resolution on the Web) may be convenient, but it is not a necessary prerequisite for having managable or persistent names. Persistence accrues from having persistent name servers, which any HTTP server can be, given that there are any number of ways to do indirect URI resolution within a server. Therefore the use or non-use of URNs is a technology choice to be made by resource owners and should not be a policy requirement imposed by standards. [For this reason, XML is *wrong* to require that notations use public IDs and not use system IDs, for example.] The only thing you know about URNs is that they will always involve one more level of indirection than the most direct URL. But the reverse is not true. That is, any URL could be just as indirect as any URN, and therefore, just as robust. Arguing about which form of name to use is a waste of time, because what's important isn't the name but the thing at the other end of it. What *is* important is the infrastructure in place for managing the indirection you need to make the names you control managable. But this issue is orthoganal to the URL/URN issue. One of the things that the Topic Map discussion should have made clear is that the idea of an "abstract thing" is bogus--there are only things. You either have only the name for the thing, in which case the name *is* the thing (because it's the only physical thing you've got) or you have the thing itself (the physical storage object the URI resolves to). In other words, if you identify a namespace with a URI which cannot be resolved to a resource (because no-one has defined the mapping from the URI to some physical object), then the URI *is* the namespace. That is, the character string that constitutes the URI is the physical (and therefore identifiable) resource that constitutes the namespace. Fortunately, the physical manifestation of a namespace is undefined, so any physical object will do to establish its identity, including a URI. If the URI can be resolved to a resource, then that resource establishes the identity of the namespace. It doesn't matter what the spelling of the URI is, only that it exists. Note that because there is no normative definition of what the definition of a namespace is (in the way, for example, that a DTD is normatively defined by the declarations in the DOCTYPE declaration or an SGML architecture is defined by its documentation and meta-DTD), all we can hope to get from the namespace declaration is establishment of identity of name spaces. That is, given two documents that both declare the use of a namespace, do they use the same or different name spaces? Since the same object can be addressed by many pointers, I would normally expect to get an object from each pointer and then see if I've gotten the same object [Note that it is up to the storage managers for the objects to determine and report identity--but that's inherent in the way computers work--since we cannot physically see and touch storage objects in most forms of media, we are dependent on the storage managers to tell us what we need to know.] If I can't resolve the pointer, then all I have is the pointer itself. If the true intent of the namespace mechanism is that the URI *is* the namespace (in the sense defined above), then they have to *disallow* resolution of the URI, otherwise, you cannot reliably establish namespace identity because two different URIs could identify the same resource. If the only objects you have are the URIs, then you know that if two URIs are different that you have two different name spaces (because the namespace objects, the URIs, are different). If namespace URIs can be resolved, then if you have two URIs, one of which you can resolve to a resource and one of which you cannot, you cannot know whether the two namespaces are the same or different because identity of the one whose URI you couldn't resolve has yet to be established (URIs cannot by themselves establish the identity of the resources they address). If you want to have namespaces for which the *only* physical manifestation is the URI of the namespace, then there must be defined a URN domain in which the URNs are their own resources. It is not enough to simply say "namespace URNs are not to be resolved", because the namespace spec doesn't have the authority to disallow the resolution of URNs. Besides, it's bogus to have namespaces that are not documented in some way, even if the namespace spec doesn't require it. Without some authoritative definition of the namespace, how can I know whether or not I'm using it correctly. Therefore, there must *always* be some resource for the name space and it is the responsibility of the namespace owner to make that resource reliably addressible within its expected scope of use. Cheers, E. -- <address HyTime="bibloc"> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. eliot@i... 2200 N. Lamar St, #230, Dallas, TX 75202 512.339.1400, www.isogen.com </address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
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
|
|||||||||
