Comments on Feb 12 Code list design document

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

Due to my focus on FPSC issues of late, I only now have the chance to 
comment on the code list document as edited by 12 February 2004.  I've 
edited out most of my comments directly related to our F2F on Monday and 
included the addition of a single new requirement brought to light by 
Stephen during that meeting:

REQUIREMENT:

That an XML instance of a UBL document type include sufficient information 
to unambiguously identify the code list from which values are used in the 
instance.  And the corollary that the schema expression convey no 
information about an XML instance of a UBL document type, only constraints 
by which an instance of the document type can be checked.  Any application 
working with a well-formed XML instance of a UBL document type shall have 
no less information about the document content than an application that 
utilizes an associated schema expression.

DOCUMENT COMMENTS:

() - 2.4.1 - "semantic clarity" - since schema mechanisms are merely 
grammars for document component labels, there can be no such formal 
"normative dereferencing" to any kind of semantic description using today's 
technologies .. I think this requirement is a non sequitur

() - 2.4.5 - context rules friendliness - isn't this speculation out of 
scope for this document?

() - 2.4.6 - any requirement to change a code list without any evidence of 
or knowing it has changed is in direct conflict to the requirement that 
code lists be unambiguously identified

() - 2.4.9 - if a code list is immutable then perhaps we shouldn't call it 
a code list ... should we be using the code list mechanism for those things 
in UBL that are hard-wired immutable enumerations?  Or should we have a 
separate mechanism for those things that are dictated by UBL from those 
things that trading partners may wish to modify to do their business together?

() - 2.5.2 - I think this is out of scope ... UBL can provide a set of 
coded values and two trading partners can choose to use an alternative set 
of coded values and I don't think it is up to us to come up with an 
expression of equivalence between members of the two sets

() - 2.5.6/2.5.7/2.5.10/2.5.11 - "nice to have" but not a requirement ... a 
schema expression is solely a set of constraints and not the documentation 
for anything

() - 2.5.8 - should this be expanded to ensure any such change must be 
identifiable as a different code list?

() - 2.5.9 - out of scope?  this might come in other documents pointing to 
the UBL CLSC Code List data model, but it isn't anything to do with our W3C 
expressions needed for UBL

() - 2.5.11/2.5.13 - out of scope?  what other people do with their meta 
data is not our business.

() - 2.5.14 - out of scope? a different list is a different list and should 
be identified as a different list and I think our schema expressions are a 
snapshot of a list in a particular state

() - 4.1 W3C Schema annotations - the prohibition of annotations was 
discussed in Montréal and I thought we came to the conclusion that such a 
facility is a W3C hack provided for those who did things with DTDs and 
shouldn't be doing with models in the first place so the fact these 
facilities exist do not mean we should be using them and the schema 
expression is not the place in which such information should be kept.

() - 4.1/4.2 - my concerns about keeping information in fixed attributes 
were articulated on Monday and I've reiterated them as part of the 
requirement voiced by Stephen above: the schema should have no document 
information, thus defaulted and fixed attributes should expressly not be 
allowed (I believe by an NDR rule if one could be made to say this)

() - 4.5 Schema Location - I do not believe this is in CLSC scope ... the 
location of schema fragments is a packaging issue for delivery of UBL out 
of the box, and once out of the box any UBL user should have free reign to 
do anything they wish with their schema fragment locations

() - 4.8 Code list types - given the title of this section I thought that 
the use of namespace-qualified names was for data types, not for element 
types and attribute names ... if they are, indeed, for element types and 
attribute names, we are getting into the discussions started at the F2F 
regarding uniquely identifying the code list from which values are taken by 
using an XML namespace for the element and attribute labels of those 
constructs in which the values are found.  I think this section would need 
to be fleshed out with examples of instance documents that would utilize 
UBL-out-of-the-box code lists and then alternative private-use code lists 
agreed-upon between trading partners (be they of their own design or from 
some other authority).

() - 4.9 Derivation - I am not familiar enough with W3C schema to judge on 
this section



I'm going back to my FPSC responsibilities now ... I hope this helps.

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

--
Public courses: Spring 2004 world tour of hands-on XSL instruction
Each week:   Monday-Wednesday: XSLT/XPath; Thursday-Friday: XSL-FO
United States: Washington, DC March 15; San Francisco, CA March 22
Finland April 26; Hong Kong May 17; Germany May 24; London June 07
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