All this buisiness about namespace URNs...

[Kent Sievers]

Clearly, if we had a DNS server that was capable of mapping the URN of a name space to a URL then the requirements would be met of having both a unique identifier and a way of getting information about the namespace.

Is someone stepping forward to do this sort of thing?  .

>>> Steve Dahl <sdahl at goshawk.com> 06/04/99 02:57PM >>>
Kent Sievers wrote:

> I see how Paul's proposal meets the "forever unique" requirement, but how is it usefull for retrieving the namespace information?

Imagine something like a DNS server, or maybe imagine subverting existing DNS servers--I don't know how well adapted or scalable they are in their current incarnations.

This new DNS-like server, rather than mapping "smtp.goshawk.com" to "38.247.98.2", would instead map:
    urn:urn-22:19990603:xml-dev at ic.ac.uk:e-mail 
..to:
    http://xml.org/XML/namespaces/e-mail 

So, when I want the documentation for the "e-mail" namespace, my browser asks the DNS-like server to map the URN to an URL, then looks up the URL as normal. If we assume that such URN servers existed, we could also assume that browsers include enough intelligence to recognize that URIs which begin with "urn:" need to be mapped through this special server.


> Reguarding the collisions, I for one would be willing to live with either 1) a "forever unique" ID or 2) taking my chances with the odds on a more descriptive ID.

Right, but the point is, there are a lot of people out there who wouldn't be willing to live with taking their chances. If you're creating your own namespace for your own project, I wouldn't dream of forcing you to use an ugly but forever unique ID. But if I were a customer who cared about long-term uniqueness, and I had to use your namespace, I might rebel against using an identifier that doesn't have any guarantee of uniqueness. Every marketplace that defines XML namespaces, or any sort of "global identifier", has to answer for itself what the most important characteristics of that identifier should
be.

And besides, who said forever unique IDs can't be descriptive? They can't be descriptive if you restrict yourself to a 20 digit integer, but if you use a more descriptive (but unique) name, they can be perfectly self-describing.


> Finnally, I think that you missunderstood me on my third question.  I never suggested making the URL part of the document.  I am proposing that it be part of the ID.   For example xmlns="xxxxxxxxx:http://www.novell.com/myproject/mynamespace"  where xxxxxxx is a "forever unique" identifier and the rest is an indication of where it can be retrieved.  The point is that the second part can be used to retreive, while the unique identifier can be used to identify and possibly perform a search in case the information is moved.  It would be replacable/ignorable without breaking the essence of the identifier.

Respectfully, no, I did not misunderstand you. What you describe here is exactly what I understood the first time. The question of whether the URL is part of the ID or is independently encoded somewhere else in the document is not important.

In general, if the URL is part of the ID, it is part of the document. Namespace ids frequently are embedded in the document. If my document's root element looks like this:

    <doc xmlns="xxxxxxxxx:http://www.novell.com/myproject/mynamespace">
        ...
    </doc>

..then the URL (by being part of the namespace ID) is part of the document, and when the URL becomes obsolete, the document contains a lie (or at best, an invalid cache). At that point, I either have a choice of modifying the document, or letting it continue to contain a very descriptive (but very wrong) URL. Neither proposition appeals to me--the first because my document may have been digitally signed, so any modification invalidates the signiture. I can't speak to the issue of leaving the URL incorrect in the ID--I don't know whether you imagine the search for the new URL based on "xxxxxxx" would be
something that any browser could do, and do quickly, or not. But (IMHO) this ability to map "xxxxxxx" to an URL would have to be something that *almost* any URL-using software could do, and do quickly and transparently--let me justify that for a moment:
    - "any URL-using software" -- if there's documentation there, we might want to see it in a browser, or if it's in a formal language, we might want to have some program read it. Both the browser and the other programs would need the ability to map "xxxxxxx" to an URL.
    - "quickly" -- so that mission critical software doesn't degrade very much even when the original URL is wrong
    - "transparently" -- because the logic of detecting a bad URL and then searching for "xxxxxxx" is not something that we want to require human intervention to do--we would (presumably) want it to just happen. Human intervention would be especially bad if this needed to be done in a batch program.

Now, assume that the act of mapping "xxxxxxx" to an URL was something most software (including browsers) could do, and it was quick, and it was transparent. If it's important enough, assume further that "xxxxxxx" is a descriptive identifier, and not just a number. If all that were true, there would be no compelling reason to use the URL that's in the identifier--if you use the provided URL, you have to include some sort of validation mechanism to make sure the URL points to a resource that matches "xxxxxxx". But assuming that searching for "xxxxxxx" is fast, you don't need to do validation on it.

If you believe all that (for example, that mapping "xxxxxxx" must be fast, therefore it will be fast), then why would we ever use the URL? And if we never used it, what was the benefit of including it in the first place?

Essentially, as I see it, you're saying that there *must* be a way to search for the current URL based on the string "xxxxxxx"--otherwise, if the URL disappears, the documentation disappears. And at the top of this message, I described how "xxxxxxx" could be mapped to an URL, with good performance. So if "xxxxxxx" is an URN, and we can map URNs to URLs transparently, isn't the URL redundant?

--
- Steve Dahl
sdahl at goshawk.com 



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)