Lists Home |
Date Index |
Title: RE: [xml-dev] Namespaces and URIs (was: A good case for Namespace URIs)
Yes, and once again the answer seems to be fairly simple. If you want to provide people with the convenience of being able to locate some information about the namespace, use an http: URL and put something there.
If you want to make it a bit (or a lot) harder for people to access your resources, use something a little more arcane that can't be conveniently resolved without prior knowledge.
I wasn't trying to do any automated processing of this namespace, just to be able to get some information about it's elements. I find it an extremely unhelpful proposal that the potential convenience of http to give hints in this issue should be discarded in the interests of pedanticism. Unfortunately, xmlns://govtalk.gov.uk/CR/core wouldn't have helped me in the slightest. Putting something at the end of http://govtalk.gov.uk/CR/core would have.
Just because the namespace URI doesn't have to be directly resolvable doesn't consitute an argument that we shouldn't take advantage of the fact that it can be. Arguing that we shouldn't use http in URLs because it makes people think that something is there may be a good academic argument but it doesn't hold a lot of water with me. I would argue that if you are prepared to take the trouble to provide some kind of human-readable resource, you should use an http URI because of it's convenience. Why avoid using it when it can give you some useful functionality?
However, it would be foolish to build software that relies on it - I expect to have knowledge of externally namespaced elements either built into the software (such as with the XSD namespace) or I will put the resource somewhere reliable and under my control and use an entity resolver. Even a resource using http can be resolved using catalogs (isn't it a wonderful thing when something can have two useful purposes concurrently).
Of course, I'd have to find it first.
From: Seairth Jacobs [mailto:email@example.com]
Sent: 04 March 2002 20:11
Subject: [xml-dev] Namespaces and URIs (was: A good case for Namespace
Okay. Once again, the issue of whether a URL used as a Namespace URI should
be resolvable or not has come up. The main confusion here is that the URI
given looks like a resolvable URL. Most people would look at it and expect
it to be able to resolve the URL to some sort of related document. As shown
with the govtalk URL though, this is not always the case. But, I can
understand the reasoning behind the use of the URL format. It is a
convenient and quick way to create a URI that is easy to remember and/or
understand (I still don't understand URNs).
However, as soon as the "http" scheme is mentioned, people start to assume
it is a resolvable URL. So how about this... why don't we just come up with
a new scheme to use instead of "http". For instance, we could have "xmlns".
Then, when seeing "xmlns://www.govtalk.gov.uk/CR/core" or preferably
"xmlns://govtalk.gov.uk/CR/core", we would know that the URL is not
resolvable (at least using HTTP). At the same time, organizations can
continue to use the URL format for its conveniences.
(SDML/GTP : www.seairth.com)
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
The information transmitted by this e-mail message is intended solely for the use of the person to whom or entity to which it is addressed. The message may contain information that is privileged and confidential. Disclosure, dissemination, distribution, review, retransmission to, other use of or taking any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message.
Although we have taken precautions to minimize the risk of transmitting viruses we nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by viruses.