----- Original Message -----
Sent: Tuesday, March 05, 2002 7:36
Subject: 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
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.
Seairth Jacobs [mailto:firstname.lastname@example.org]
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
it to be able to resolve the URL to some
sort of related document. As shown
govtalk URL though, this is not always the case. But, I can
understand the reasoning behind the use of the URL format. It is
convenient and quick way to create a URI that is
easy to remember and/or
understand (I still don't
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
"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
use the URL format for its conveniences.
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
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.