Re: [codelist] Dissenting argument on namespace URI

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Many thanks, Ray, for submitting this document.  I had some thoughts 
to share at the meeting that was cancelled, and will bring them up 
tomorrow, but thought I'd share them first on the list to spark more 
threaded discussion.

At 2007-03-08 11:09 -0500, Ray Denenberg, Library of Congress wrote:
>I appologize if I'm not following procedures for properly submitting a
>document, but I haven't figured it out yet.  Meanwhile I've attached a word
>document (I'm not even sure this listserv takes attachments but I've copied
>Ken too so he'll get it).  If someone can point me to the procedures for
>submitting this properly I'll do it.
>
>Anyway, at the last call I agreed to write up my argument about XML
>namespace URIs; it's attached.

Having taught XML namespaces as part of my hands-on training classes, 
I'm well aware of the distinctions made between identifiers and 
locators, and you've done an excellent job in overviewing the issue, 
your observations, and the historical debate.

It is unfortunate that being condescending is perceived when hearing 
the argument that "well, the URI string syntax allows "http" it to be 
used without needing to dereference it", when in fact I understand 
this to be true.

I'm unfamiliar with the info: URI scheme so I appreciate the 
information you've included.

I am familiar with the improper use of the "urn:" namespace, 
particularly in the US government where I've seen the incorrectly use 
of "urn:us:..." when "us" is not a registered namespace identifier 
(as "oasis" is).  Personally I'm a big user of the private 
unregistered use of urn: as in my use of "urn:x-CraneSoftwrights" as 
abstract pointers within documents such as RSS references (but not 
outside of documents).

Reading your documented remarks on "Confusion and its repercussions" 
I am not swayed.  XML is a labeled hierarchy of information items, 
and namespaces are used to create rich labels with global 
uniqueness.  Nothing more.  The fact that people do not understand 
this does not, in my opinion, invalidate its use.  On the contrary, 
the more that it is used properly the more others may learn to use it 
properly.  Avoiding its correct use does not propagate its correct use.

I feel your paper doesn't weigh in to the *benefits* of using an URI 
that (1) takes advantage of existing ownership of domain names, and 
(2) *happens* to be a URL that can be used for documentation and RDDL[1].

Regarding (1), if I wanted to use info: for a namespace then I have 
to go to the effort of registering it, however today, without effort, 
I can manage my own namespace URI strings if I choose the http syntax 
and use the domain name I already own and is already globally unique.

Regarding (2), there is no obligation to have a URL for the URI, but 
having an XHTML document at the URL for the URI opens up the 
opportunity for additional features and benefits to help users 
(especially users who don't understand that the URI is not a pointer 
to a schema or any constraint definition) do resource discovery.  I 
see using XHTML/RDDL as a way to help users understand the role of a 
URI that just happens to be a URL.

But I acknowledge your user experiences are different than my user experiences.

I'm really worried about going the "info:" route (is OASIS planning 
to get an info registration? you mention info:xmlns/oasis which would 
require two registrations and maintenance of the level below xmlns 
... who would maintain that?), and I'm slightly worried about going 
the "urn:oasis:" route because of lost opportunity, and I'm very 
interested in trying the "http:" route with XHTML and RDDL as a 
testing ground to measure the success of using the URL as a URI.

Though of course "testing" something that is being made permanent is 
a really tough test ... once we make up our mind here for genericode 
1.0 then I see us setting a precedent for genericode through its 
lifetime ... but we really won't be able to measure its success until 
we try it.

So, personally, I was seeing this as an opportunity to exercise the 
specifications for which they were designed ... not avoiding a 
non-technical issue (yes I know you've identified it as a usability 
issue, but it isn't a technical issue in my opinion).  We can 
continue using the standards in the ways in which they are specified 
to work which can help the community with examples of the proper ways 
of using the specifications.

Given that each committee can have its own repository, I'm suggesting 
we use something like:

   http://docs.oasis-open.org/codelist/ns/genericode/1.0/

as the namespace URI with an index.html at that directory in XHTML 
with RDDL statements, copies of the schema files in that directory as 
a central resource that anyone can point to, and any other 
information in support of the base specification.

I understand we have polar opposite opinions on this with strong 
feelings behind both and, as a committee, we have to find a way to 
move forward.  The two suggestions on the table so far to consider are:

   info:xmlns/oasis/codelist

and

   http://docs.oasis-open.org/codelist/ns/genericode/1.0/

Would other members of the committee please give your opinions and 
other suggestions for consideration?

I hope this is perceived as a healthy debate, Ray, and not just as a 
contrary opinion.  Thank you very much for bringing forward your 
ideas in such a detailed fashion.

. . . . . . . . . . . . . . . . Ken

[1] http://www.openhealth.org/RDDL/20040118/rddl-20040118.html

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal