[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
>Date: Thu, 26 Feb 2004 10:53:11 -0500 >From: "Eve L. Maler" <Eve.Maler@Sun.COM> >Subject: Re: Wednesday's code list "meta-data block" implementation proposal >To: "G. Ken Holman" <gkholman@CraneSoftwrights.com> >Cc: UBL CLSC <ubl-clsc@lists.oasis-open.org>, > A Gregory <agregory@aeon-llc.com>, tmathews@lmi.org >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: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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]