Overloaded URIs must GO!

[Charles Reitzel]

Must this same discussion be repeated endlessly?  In its essence, it has
changed not a whit in a year.  Indeed, many of the participants are the
same.  As folks have pointed out, it is an important subject upon which many
pieces of software depend.  So I am merely expressing dismay that reasonable
conventions have not sorted themselves out.

Question: wouldn't it be reasonable for URN's in some schemes to be
overloaded?  For example, couldn't some portion of a namespace URN be the
schema or dtd file declaring the namespace contents?  Any host serving up
documents (or portions thereof) using the namespace could easily resolve the
filename and return the schema/dtd file itself.

urn:<NID>:<name space>

urn:xmlns:joebob/schema/widgets.dtd

Generally, http servers and their ilk do *not* need literal paths to files.
All kinds of path tranlation is performed.  Thus, there is plenty of
opportunity to resolve the name to a concrete resource (and return a "not
found" if the request is not meaningful).  Conventions like *not* including
a file extension in the URN if the namespace is abstract will go a long way
to helping NS users avoid making such requests.  

As many have said, it would be useful to have an explicit mechanism to
reference a dtd/schema document associated w/ a namespace.  Without such a
mechanism, URN overloading is practically a requirement.

Also, some folks are reasonably concerned about permanance.  They don't like
DNS names in URNs because DNS could go down or the domain name could become
unregistered and then reregistered to someone else using the name in a
completely different context, etc. etc.  

For applications that need it, I would investigate getting an ISO Object
Identifier.  Your organization can get a globally unique number from the ISO
which identifies your organization and can be extended to identify important
entities it publishes.  

Like DNS, you just get the one ID from the global registry which may then be
used to qualify any additional IDs you define.  Unlike DNS, there is no
particular association with a given piece of software or data format and the
registration body will not unregister your ID if you don't make annual payments.

It shouldn't be too hard to use an OID within a URI/URN (you pick).  If it
is,  go bug the appropriate IETF WG, because it shouldn't be.

At any rate, I think the XML community can look to de facto standards
(MIME/HTTP) for resolution of schema documents and standards bodies for
permanent ID registration.  It isn't *that* hard.

Best regards,
Charles Reitzel

>From: "Jonathan Borden" <jborden at mediaone.net>
>Subject: Re: Paul has volunteered (was Re: Overloaded URIs must GO!)
>
>Paul Prescod wrote:
>>
>>But there are specifications being built on top of the namespaces
>>specification that make use of the URI. These specifications are not right
>>or wrong -- the namespace spec is silent about what happens if you
>>dereference the URI.
>>
>>When these specifications are deployed, software will attempt to
>>dereference namespace URIs. That software will not know whether to report
>>inaccessible URLs as errors or retry on the hope that it is available now
>>or merely assume that that namespace doesn't have an associated document.
>>Do we report an error or merely continue?
>
>    This is a very difficult problem without an easy solution.
>
>    This problem will arise with most data whose lifespan is expected to be
>long. Short term problems include network outages as well as firewall
>issues. Longer term problems include changes in DNS ownership. Still longer
>term problems include changes in network protocols (i.e. when http becomes a
>legacy and/or unsupported protocol).
>
>    The only good solution to this problem is to keep schemas/DTDs together
>with documents and not depend on any network protocol.
>
>    URNs aren't a solution to this problem, because URN's don't allow
>dereferencing (otherwise they become another type of URL). Wouldn't it also
>be an error to attempt to dereference "urn:xxx..."?
>
>Jonathan Borden
>http://jabr.ne.mediaone.net
>


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)