OASIS Code List Representation TC

Fellow code list committee members,

I'm almost finished the latest schema and documentation changes for 
the next revision of the context/value association (CVA) vocabulary.

This is probably the last chance for a possible change that I've been 
pondering, and I want to get the committee feedback on this change.

The genericode XML vocabulary was (and still is) the only XML 
vocabulary I've encountered where the document element is in an 
identifying namespace while every other element in the document is in 
no namespace.

The original and current draft CVA vocabulary uses the identifying 
namespace on every element in the document, very typically seen in 
almost every other document model qualified with a namespace.  XHTML 
and XSL-FO are just two examples that you could look up if you wanted 
to, but in fact I cannot easily think of any XML namespace-qualified 
vocabulary that doesn't put all of its elements in one or more 
namespaces rather than only the document element.

Since both the genericode and CVA vocabularies are coming from the 
same committee, should the CVA vocabulary follow the precedent set by 
genericode and put only its document element into the CVA namespace, 
leaving all other elements in no namespace?

Our users would then be presented with the same vocabulary design 
philosophy for both CVA and genericode.

Tony, can you comment on your original decision to do this?  I've 
found it makes writing stylesheets supporting multiple versions very 
easy (as when I support both genericode 0.4 and 1.0).

Thank you all for your thoughts on this.  The sooner you can comment, 
the sooner I'll be able to produce the next version.

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

--
XSLT/XQuery/XSL-FO training in Los Angeles (New dates!) 2009-06-08
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Hearing no comments, I'll proceed by making the change to make a CVA 
file use of namespaces consistent with the genericode use of 
namespaces.  Only the document element will be namespace qualified.

Another use case for CVA files has been raised in the work on the UBL 
project, so the next revision will have a number of changes.

. . . . . . . . . Ken

At 2009-04-14 19:53 -0400, I wrote:
>Fellow code list committee members,
>
>I'm almost finished the latest schema and documentation changes for 
>the next revision of the context/value association (CVA) vocabulary.
>
>This is probably the last chance for a possible change that I've 
>been pondering, and I want to get the committee feedback on this change.
>
>The genericode XML vocabulary was (and still is) the only XML 
>vocabulary I've encountered where the document element is in an 
>identifying namespace while every other element in the document is 
>in no namespace.
>
>The original and current draft CVA vocabulary uses the identifying 
>namespace on every element in the document, very typically seen in 
>almost every other document model qualified with a namespace.  XHTML 
>and XSL-FO are just two examples that you could look up if you 
>wanted to, but in fact I cannot easily think of any XML 
>namespace-qualified vocabulary that doesn't put all of its elements 
>in one or more namespaces rather than only the document element.
>
>Since both the genericode and CVA vocabularies are coming from the 
>same committee, should the CVA vocabulary follow the precedent set 
>by genericode and put only its document element into the CVA 
>namespace, leaving all other elements in no namespace?
>
>Our users would then be presented with the same vocabulary design 
>philosophy for both CVA and genericode.
>
>Tony, can you comment on your original decision to do this?  I've 
>found it makes writing stylesheets supporting multiple versions very 
>easy (as when I support both genericode 0.4 and 1.0).
>
>Thank you all for your thoughts on this.  The sooner you can 
>comment, the sooner I'll be able to produce the next version.
>
>. . . . . . . . . . . Ken


--
XSLT/XQuery/XSL-FO hands-on training - Los Angeles, USA 2009-06-08
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

I thought I would share an interesting byproduct of this decision.

I am now able to cut out the "duplicate definition" of the genericode