TC Guidelines for namespace URI strings

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

Hi folks, please bear with me while I expose my line of thinking in regard 
of namespace URI strings for projects in SBSC and HISC.  I introduce why we 
need to think of this, the problems I have assessing the NDR guidelines in 
this situation, and how I'd like to proceed.  By spelling this all out, I 
hope it reduces the time for debate.

In SBSC and possibly HISC we do and will need to create vocabularies for 
internal committee work and work that eventually may become part of 
published standards.

For example, I created a small vocabulary to capture XPath information ... 
it has nine elements and attributes.  I didn't bother with a namespace 
since it was a simple vocabulary.

However, rather than use no namespace, I've been asked to put the 
vocabulary into a particular namespace, so I need to choose a namespace URI 
string.  I figured something like:

   urn:oasis:names:tc:ubl:sbsc:xpath

That allows us to create any number of internal-use-only URI strings.

Eventually, though, I anticipate this vocabulary will be published as part 
of the SBSC specification ... but are we obliged to create a W3C Schema for 
the simple vocabulary?  I have created a normative RELAX-NG schema that 
captures all of the validation requirements.  In this vocabulary's case, 
W3C Schema is not expressive enough to capture all of the validation 
requirements, though on request I have created an insufficient W3C Schema 
expression that validates most of the requirements.

I'm reading through cd-UBL-NDR-1.0Rev1b.pdf and I get contrasting vibes 
regarding whether these are guidelines for *all* vocabularies, or just 
"e-commerce document types" and "UBL document schemas".  I'm not using core 
components, and I don't have metadata models or information entity diagrams 
... I'm just creating a simple vocabulary for capturing XPath 
information.  But, as I said, the vocabulary will probably be made public.

So, my quandaries:

(1) The W3C Schema is insufficient for this particular vocabulary, so I 
really don't think we should use it.

(2) What URI strings do I use?  NMS4 states for draft status:

   urn:oasis:names:tc:ubl:schema:<subtype>:<document-id>

NMS5 states for standard status:

   urn:oasis:names:specification:ubl:schema:<subtype>:<document-id>

*All* of the examples in NDR for <subtype> are "xsd", but that implies 
there exists a normative W3C Schema, which I claim we must not use since 
W3C Schema cannot normatively express all of the constraints.  So, I'd like 
to put RELAX-NG here, but there are two isomorphic expressions of RELAX-NG 
constraints: the full XML syntax and the compact text syntax.  Filename 
extensions adopted in the community for these are, respectively, ".rng" and 
".rnc".  Neither of these abbreviations would be appropriate since there 
could easily be two equivalent expressions of the vocabulary constraints 
and I don't want to infer that one is better or more normative than the 
other.  In some situations people may wish to use one expression or the other.

So, that leaves me with the draft work using:

   urn:oasis:names:tc:ubl:schema:relax-ng:XPath-1.0

and the published work using:

   urn:oasis:names:specification:ubl:schema:relax-ng:XPath-1.0

In our last XPath package I included the normative RELAX-NG expression of 
constraints using the compact text syntax, and an informative incomplete 
W3C Schema best-effort expression.

In our next XPath package, I would like to use the above namespace URI 
strings for the vocabulary.

Will there be any objections for us doing so?

Thanks for your feedback!

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

--
World-wide on-site corporate, govt. & user group XML/XSL 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 Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal