Re: Review and URN assignment for draft-seantek-xmlns-urn-00

[Sean Leonard <[e-mail]>]

On Nov 12, 2014, at 7:02 AM, Dale R. Worley <[e-mail]> wrote:

>> From: Sean Leonard <[e-mail]>
> 
>>> I assume that means "This draft provides an XML namespace designer
>>> with the option...", even though the "now" in that sentence is
>>> ambiguous -- does it refer to the time before adoption of the draft or
>>> after?
>> 
>> Yes. After adoption of the draft.
> 
> Does that mean, "We will edit the text to make that clear.”?

Yes.

> 
>> That is correct. However, urn:oid (and for that matter, oid: ) and
>> tag: URIs are not really used in practice.
> 
> It's true that they're rarely used, but whose problem is that?  There
> should be no reason that they *can't* be used.  The real problem (as
> you say in text I deleted) is that they're not *mnemonic*.  As you
> note below, the mnemonic feature is crucial for your proposal.

I agree that being memorable is a goal. However, it is not the only goal. At least one other key goal that the proposal describes is associating XML namespace semantics with the URI, namely by including a description of the namespace in the registry, and by operationally associating the URN with URIs that might have more information (such as schema definitions or syntax specifications).

A tag: can be used as an XML namespace, but if you pass tag: to an URI dereferencer, it’s not going to retrieve any representations. The idea is that if you pass urn:xmlns to a URN resolver, the URN resolver will be able to get relevant URIs by association.

> 
>> So to answer the question specifically: the namespace is beneficial
>> to XML namespace designers who want to have short, mnemonic, unique,
>> long-lived URIs, and to XML namespace users (that would be “everyone
>> on the Internet”) who rely upon them. You can still use other URIs
>> for XML namespaces, but this URN namespace is tailor-made to satisfy
>> the needs of that subset of users.
> 
> I'd like to see that written into the document as well, as that is the
> real description of the purpose of the draft.

Ok. Good point.

> 
> Is there truly a lot of demand for these, in particular the "short,
> mnemonic" aspects?  I can't think that I would care myself, and I've
> named XML namespaces.  (I used http: URLs based on the company's
> domain.)

It gives more options.

One reason I wrote it was to deal with the brouhaha on [e-mail] about fragments (so-called “f-components”). XML namespaces don’t use fragments much, but RDF does. This proposal represents one attempt to deal with fragments in a systematic and URN + URI-compatible way.

(Note that ? is not a valid character in an XML Name, so the issue of so-called “q-components” is conveniently avoided.)

> 
>> Compare for “Foo Description Language Version 2":
>> http://www.acmecorp.com/xml/foodlv2
>> tag:acmecorp.com,2014:foodlv2
>> urn:xmlns:acme:foodlv2
> 
> I think to a degree the comparison is unfair.  Acme Corp. has the
> domain name "acmecorp.com" because "acme.com" was taken.  Which means
> that "urn:xmlns:acme" was likely to also have been taken, so Acme
> Corp. will be using "urn:xmlns:acmecorp:..." or some such for their
> URNs.  That lengthens the final example to
> "urn:xmlns:acmecorp:foodlv2", which is still the shortest but is now
> only 3 characters shorter than example 2.

That is true…but the comparison may not necessarily be unfair.

The minimum HTTP URL would be:
http://acme.co/foodlv2

= 22 chars

actually, the REAL minimum URL would be:
http://x.acme/foodlv2

= 21 chars

thanks to ICANN’s new policy/cash cow of charging for TLDs. :)

the most minimum URNs would be:
urn:xmlns:acme:foodlv2

= 22 chars

or
urn:xmlns:foodlv2

= 17 chars

or (if you want to compress foodlv2, which you can because it’s in the acme-divided area)
urn:xmlns:acme:f

= 16 chars

The human mind wishes to fill in gaps and organize things into neat categories. Any of these could be acceptable. But the proposal has less to do with minimum characters, and more to do with avoiding encoding things that don’t matter to the task at hand.

An issue with HTTP URLs is that you’re sharing a namespace with the web server, and with the DNS infrastructure. I.e., http://acme.co/xml/foodlv2 requires reserving some directory for XML things instead of regular webpages; it also requires that you keep on paying for acme.co if you want the “association” semantics (as well as the uniqueness guarantees: the next owner of acme.co could devise another unrelated foodlv2 spec, and would never know that someone else came beforehand to define a prior one). And since it’s .co, it depends on the geopolitical situation with the nation of Colombia. (Compare with .ly, which was quite popular a couple of years back.) These are unnecessary dependencies for a one-off identifier.

If a random identifier is sufficient,
urn:uuid:9416c1d6-1c1c-4939-84c3-c730b0310418
will suit any namespace identifier purpose just fine. But the human mind is going to reject that in favor of something with a bit more internal and external meaning. (Internal = it has names like “acme” in it; External = you can dereference the URI to get useful things like syntax specifications or schema definitions.)

Sean