Wednesday's code list "meta-data block" implementation proposal

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

Two requirements not present in the 2004-02-12 code list representation 
working draft are:

(A) - that the supplementary components of the code lists of code list 
values utilized in a UBL instance be available in the XML instance proper 
without any processing from any external source including any schema expression

(B) - that the supplementary components be available for all 
code-list-value information items even when two or more such information 
items are found in the set of #PCDATA and attribute information items for 
any given element

One interpretation of the approach that was floated today (termed 
colloquially as the "meta-data block" approach) is as follows:

(1) - every UBL document shall have as many code list meta-data 
declarations as code lists from which values are used in the document

(2) - all code list meta-data declarations shall be grouped in a container 
element at the start of the document

(3) - a validated UBL document has confirmed that for every code list-based 
information item in the instance there exists a code list meta-data declaration
- validation of an XML instance does require two processes, one expressed 
in W3C schema constraints and an application-level constraint check that 
cannot be expressed using W3C schema.  At the meeting I conjectured that it 
could all be done in W3C schema but only when writing it up did I realize 
that the optional nature of code list values in the instance requires the 
cardinality of the meta-data block to be optional and there are no W3C 
schema co-occurrence constraints to check the presence of two optional 
components.  It was noted at the meeting that one should be able to express 
this constraint in Schematron assertions.

(4) - two ways of declaring the association of supplementary components, 
both of which utilize a generic UBL code-list meta-data declaration 
container as the first child element of the document element, dereference 
the association differently:

(4.1) - the code list meta-data declaration consists of a generic UBL 
element type and a required URI-typed attribute identifying the namespace 
URI of the code list from which a coded value is used in an information 
item with the same namespace URI, and optional attributes for the 
supplementary components

      <in:invoice xmlns:curr="---arbitrary-currency-URI-here"
                  xmlns:in="---UBL invoice--" xmlns:cl="---UBL code list---"
                  ...>
        <cl:meta-data-block>
           <cl:meta-data ns="---arbitrary-currency-URI-here"
                         agency="xxx" version="yyy" .../>
        </cl:meta-data-block>
        ....
        <amount curr:currency="CAD">123</amount>

(4.2) - the code list meta-data declaration consists of an element type 
whose namespace URI matches the namespace URI of the code list from which a 
coded value is used in an information item with the same namespace URI, and 
optional attributes for the supplementary components

      <in:invoice xmlns:curr="---arbitrary-currency-URI-here"
                  xmlns:in="---UBL invoice--" xmlns:cl="---UBL code list---"
                  ...>
        <cl:meta-data-block>
           <curr:meta-data agency="xxx" version="yyy" .../>
        </cl:meta-data-block>
        ....
        <amount curr:currency="CAD">123</amount>

Both 4.1 and 4.2 are naming issues and are orthogonal to the data types and 
other code list schema fragment issues.  Refer to the code list 
requirements documents and other CLSC members for data type issues (that I 
am not familiar with; I'm focused on this naming requirement).

Method 4.1 allows for a single generic declaration of the meta-data block 
and its contents, not requiring when adding one's own custom code list any 
schema changes to the meta-data block (though schema changes are required 
for the custom code list use and probably data type).

Method 4.2 requires changing the schema for the meta-data block when also 
changing the schema for a custom code list.

Out-of-the-box-UBL defines the code list namespace URI strings for all of 
the code lists (and they are arbitrary and need not have namespace URI 
fields) ... but because they are arbitrary, a user can change in the 
instance a code list's supplementary components without any validation they 
are the same supplementary components as out-of-the-box-UBL.

Does this last point mean we've missed the boat (again!) because two 
trading partners can use the same schema and same URIs but change the 
supplementary components in the instance?  Or are business issues covered 
because any changes to the supplementary components are, indeed, in the 
instance and not hidden anywhere?  Stephen, are legal concerns addressed by 
all this?  Or is this a "feature" for the end user of UBL?

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

p.s. I'll reiterate again that I'm helping document the discussions this 
week on naming of information items with coded values, but that I am *not* 
the person with which to discuss the latest CLSC paper and issues of data 
types ... I've posted my comments on that to the CLSC list earlier today 
for input into the discussion by the CLSC group

--
US XSL training: Washington,DC March 15; San Francisco,CA March 22
World-wide on-site corporate, government & user group XML 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