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

MHonArc v2.5.0b2 -->
















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Fwd: Re: Wednesday's code list "meta-data block" implementation proposal




From: "G. Ken Holman" <>
To: Universal Business Language <>
Date: Thu, 26 Feb 2004 13:14:18 -0500








>Date: Thu, 26 Feb 2004 10:53:11 -0500
>From: "Eve L. Maler" <>
>Subject: Re: Wednesday's code list "meta-data block" implementation proposal
>To: "G. Ken Holman" <>
>Cc: UBL CLSC <>,
>    A Gregory <>, 
>X-Accept-Language: en-us, en
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
>  Gecko/20030624
>
>Hi Ken and everyone,
>
>G. Ken Holman wrote:
>
>>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
>
>While I made that argument mildly yesterday, I can see how a namespace URI 
>made up of special parts can become known by processors as the 
>(opaque-string) "name" or "identifier" of that particular mix of 
>options.  So this isn't as important to me as the oddity of requiring 
>namespace URIs to have a certain format, no matter who's assigning them.
>
>>(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
>
>At the minimum, of course, you get this for free because of the reliance 
>on XML namespaces for code.  <foo:elem>code</foo:elem> and <elem 
>bar:att="code"/> both require foo: and bar: to be "declared".  The next 
>issue below is where it gets more complicated.
>
>>- 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.
>
>I'm not sure I understand the concern here.  It was always the case, 
>because of XSD's lack of co-occurrence constraints, that all the 
>supplementary components for codes had to be "optional" and we had to 
>document "patterns" of usage depending on the type and source of the code 
>list.  The February 8 code list document shows this in Section 3.3, 
>"Examples of Use".  It's never the case that *all* of the supplementary 
>components need to be filled in, because some pairs of them provide 
>alternative means of supplying the same basic info ("what agency is this 
>from?" etc.).
>
>So in both the new proposal and all previous proposals considered, it was 
>never possible to use XSD to enforce provision of the "right" set of 
>supplementary components.  I just realized that with a variation on the 
>meta-data block proposal, by the way, this *could* be enforced!  You could 
>have a unique meta-data block element for each pattern, like so:
>
><!-- all attribs required -->
><codelist-managed-by-de3055-agency
>   xmlns:...="..."
>   listID="..."
>   listVersionID="..."
>   listAgencyID="..."
>/>
>
><!-- all attribs required -->
><codelist-managed-by-other-std-agency
>   xmlns:...="..."
>   listID="..."
>   listVersionID="..."
>   listAgencyID="..."
>   listAgencySchemeID="..."
>   listAgencySchemeAgencyID="..."
>/>
>
><!-- etc. -->
>
>But this may very well be overkill, which is perhaps why we haven't 
>considered it before.  It would have been possible to add it to the 
>datatyping proposal we've got now.
>
>>(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>
>
>(I would imagine that cl:meta-data-bock could be in the common module and 
>not need a namespace that's unique to code lists...)
>
>>(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.
>
>The only benefit I can see for method 4.2 is that the code list schema 
>module that actually defines the relevant simple type constraining code 
>values could have the same namespace and could be made to contain the same 
>"code list declaration", which has benefits for in-place documentation of 
>the code list schema module itself.  But there are other ways to achieve 
>this, without the added cost of changing the meta-data block schema every 
>time you touch the code list schema module.
>
>>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.
>
>I'm not sure I understand this, though it may be because I haven't kept up 
>with the latest status of OOTB UBL on this point.  But our previous 
>datatyping solution certainly allowed code list owners to set up code list 
>schema modules with supplementary-component attributes whose values were 
>*not* fixed, which could have allowed UBL document creators to mess with 
>the values of those attributes right in the instance, right next to the 
>relevant code.  The same sort of abuse (?) thus would have been possible 
>before.
>
>>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?
>
>I believe that we need to think of the code list schema module's target 
>namespace as the "real" namespace URI assignment, and the declaration of 
>that namespace URI in a meta-data block as a *reference* to the namespace 
>defined by the code list owner, in precisely the sense that supplying a 
>code is intended to convey a *reference* to the real, official meaning of 
>that code as defined by its owner.  Anything else is madness.
>
>As long as a sender creates a UBL document that (a) supplies a valid code 
>in an element/attribute field and (b) references the intended code list 
>namespace URI, the recipient (along with any intermediate auditors) gets 
>both semantic clarity and "availability" of those semantics, albeit with 
>the thinnest possible indirections from the point of code usage to the top 
>of the document.
>
>>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
>
>I've commented a bit here on the connection of this proposal to the code 
>list schema module.  Ideally the final worked example will make this 
>connection explicit and test it to make sure it holds up.
>
>Talk to you folks soon,
>
>         Eve
>--
>Eve Maler                                        +1 781 442 3190
>Sun Microsystems                            cell +1 781 354 9441
>Web Products, Technologies, and Standards    eve.maler @ sun.com


--
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:
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