Re: [codelist-comment] Genericode feedback and the relationship to CCTS CodeType

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

Thank you, Kurt, for your post to the comment 
list.  Please pardon my tardy response but I've 
been traveling in Asia and busy with meetings day and night.

At 2007-12-07 17:12 -0500, Kurt Kanaskie wrote:
>Through collaboration with fellow OAGi architects I came across the
>genericode work. I think this is an important topic from the perspective of
>standardizing code set representation such that it can be used in XML
>instance validation, even if it requires 2 pass validation or alternative
>validation beyond Schema. I can only imagine in the future there is
>potential for this functionality being built into parsers/tools, much like
>some do now for Schematron.

Indeed ... I agree it is getting attention.

>So considering industry standards have adopted CCTS with the associated
>CodeList attributes there is opportunity to validate XML instance documents
>based on these attributes and their relationship to genericode
>representations of the code set.

Please consider our existing work on the 
context/value association (CVA) file specification in our project:

   http://www.oasis-open.org/archives/codelist/200711/msg00007.html

While genericode specifies list-level and 
item-level meta data, the CVA specification 
allows one to specify instance-level meta data 
and the expectations between trading partners of 
the use of published, extended and restricted genericode files.

>To understand the feasibility of such a
>solution, consider a practical application based on Stylesheets and
>Schematron.

I quite agree!  Please find a working 
implementation of CVA files published last month:

   http://www.oasis-open.org/archives/codelist/200711/msg00009.html

This implements CVA files using Schematron, and 
implements the Schematron using XSLT 1.0.

The CVA specification does not constrain the 
mechanics of how the interpretation of a CVA file 
is to be implemented ... someone applying 
context/value association and genericode to a 
database won't be in a position to use Schematron.

>An example solution might be:
>
>·         Decide on a code set and represent that in genericode (e.g.
>CountryGenericodes.xml)

(we've been using the ".gc" extension, but that is a triviality)

>·         Choose names for the code set and use both in the genericode
>instance and the CCTS based XML instance that will be validated.

As Tony mentioned, this work already has the 
attention of CCTS and they have committed to 
publishing their lists of codes as genericode files next year.

>·         This requires a mapping between genericode elements to CCTS
>CodeListType attributes, for example using the OAGi representation of a
>CodeType:
>
>o    oa:Code/@listName === /gc:CodeList/Identification/ShortName
>
>o    oa:Code/@listID ???
>/gc:CodeList/Identification/LongName[@Identifier="listID"]
>
>§  This is where the examples put ISO3166-1 in the genericode documentation?
>
>o    oa:Code/@listURI === /gc:CodeList/Identification/LocationUri
>
>o    oa:Code/@listSchemeURI === this would be the genericode schema location
>
>o    oa:Code/@listAgencyName === /gc:CodeList/Identification/Agency/LongName
>
>o    oa:Code/@listAgencyID === /gc:CodeList/Identification/Agency/Identifier
>
>o    oa:Code/@listVersionID ===
>/gc:CodeList/Identification/CanonicalVersionUri

This mapping has been done in the Universal 
Business Language, and in the Schematron 
implementation from Crane's web site you'll see 
documentation that reflects the above mapping.

>·         Validate instances for each occurrence of a Code element in a
>context such as oa:Classification/oa:Codes:
>
>o    oa:Code/@name look up using XPath
>
>§
>document(oa:Code/@listURI)/gc:CodeList/SimpleCodeList/Row/Value/[@ColumnRef=
>"name"]/SimpleValue
>
>o    oa:Code look up using XPath:
>
>§
>document(oa:Code/@listURI)/gc:CodeList/SimpleCodeList/Row/Value/[@ColumnRef=
>"code"]/SimpleValue
>
>o    Verify the Code and the Code/@name exist and are in the same Row.
>Validation success or failure.

Yes, you could do it procedurally in XSLT ... but 
with a CVA file you are doing it declaratively 
and allowing an interpretation of the CVA file to do the above.

Another aspect of what you propose above is the 
run-time nature of XSLT and looking up the 
genericode file.  In the Schematron-based 
implementation I created at Crane, I dereferenced 
all of the externally-declared values and wrote 
them into the intermediate Schematron schema, 
thus they get included directly into the XSLT 
stylesheet created for the schema, thus there is 
no use of the documentation at run time when actually validating a document.

This was thought to be a better use of time and 
resources:  do all of the fetching only when the 
code list changes, preparing a runtime artefact 
that can be optimized as best as possible.

>This demonstrates the concept behind my idea (probably not original) of
>using BOD instance Code attributes to identify an external Code Set XML
>instance document that is used to validate the content. This would be a
>consistent design approach that could be used for any “standard” CCTS and
>genericode based solution. It could also be easily coded in Schematron as an
>abstract rule.

Absolutely!  Or, if the Schematron schema is 
being synthesized from CVA files, no coding need 
be done ... it can just be declared.

When you download the UBL 2.0 package you'll find 
the runtime artefact defaultCodeList.xsl ... this 
was first implemented in January 2006 ... it is 
based on an early specification of CVA files that 
I first proposed in August 2005 at the UBL F2F 
meeting in Ottawa.  Users of UBL get CCTS code 
list validation "off the shelf" as an XSLT file 
created from the genericode files found published in the UBL package.

>What I don’t like about the genericode solution is:
>
>1.  The apparent disregard for semantic naming alignment with CCTS CodeType
>attributes, why not align them more directly?

Because CCTS is not the only specification 
choosing to use genericode.  Tony's hard work in 
other committees triggered his creating 
genericode to meeting the needs of many 
groups.  Why favour one group over another?  Tony 
chose names to reflect the abstract semantics of code list identification.

>2.  The open content needed to represent the name and code in the Row/Value,
>why isn’t this a semantically named element?

Because values may be simple, or they may be 
richly structured.  There are no constraints on 
genericode columns, so users need the flexibility to declare what they need.

>3.  No place for the @listID, it’s done using open content in an
>Identification/LongName with an @Identifier set to “listID”. At least that
>is how the examples in “Code List Representation (Genericode) Version 1.0”
>did it. This seems like such an important concept that it should be explicit
>with a semantically named element or attribute.

Semantically, there are two kinds of 
names:  short (a token) and long (a string) ... 
there doesn't seem to be a need to introduce yet 
another semantic kind of name.  To distinguish a 
long name used as an identifier and a long name 
used for other purposes, the attribute 
qualification would be the appropriate way to do 
it.  If on the surface this seems a bit 
parsimonious, I think Tony has employed good XML 
design principles in deciding what has gone into genericode.

>Apart from that, I think it’s good that there is work on standardizing how
>to represent a Code Set but it really needs to be aligned with the CCTS work
>to ensure it can be used in real world situations.

Crane has already published two adaptations of 
CVA files to particular vocabularies:  one for 
UBL and one for any vocabulary that does not have 
instance-level code list meta data.

Above you cite:

   oa:Code/@listName
   oa:Code/@listID
   oa:Code/@listURI
   oa:Code/@listSchemeURI
   oa:Code/@listAgencyName
   oa:Code/@listAgencyID
   oa:Code/@listVersionID

You can adapt the Schematron implementation to 
OAGi requirements, or, if you write to me off 
this list (this list is reserved for comment) and 
characterize for me how the implementation would 
recognize information items that are populated by 
code lists (is there an unambiguous naming 
convention?  if not, is there a catalogue of 
element names?), and give me a couple of test 
files, then I can see if I can make the time to 
add an OAGi/CCTS implementation to the 
freely-downloadable resource.  I think this would 
be a valuable addition to the download.

But, of course, you could just do it yourself.

I hope this has addressed all of your issues ... 
thankfully, I believe your stated requirements 
are ably being met by the proposed CVA file 
specification.  We hope there will be a number of 
CVA file implementations, and a Schematron one is 
already available for anyone to use today.

BTW, the proposed CVA file specification is not 
finalized ... your participation would be welcome 
if you joined OASIS and our committee!

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

p.s. Having addressed your original comments, 
discussion should not continue on this comment 
list ... I have started a developers' list that 
the general public is welcome to join (you do not 
have to be a committee member):

   http://www.oasis-open.org/archives/codelist/200712/msg00000.html

... we can continue this on that list if you wish.

--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and 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 Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal