Concept of code list templates for UBL 2.1

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

One of the questions coming up for the UBL 2.1 
packaging we'll be prototyping in Montréal is that of "template code lists".

This would entail a couple of changes to the strategy document I posted here:

   http://www.oasis-open.org/committees/document.php?document_id=33456

This was a hidden or implicit concept in UBL 2.0 
regarding information items that were governed by 
coded lists but for which there were no code 
lists to use.  Through automation I synthesized 
metadata-only genericode files for all of the 
information items that we didn't have code lists 
for and I put these in the same directory as the 
genericode files we did have code lists for.

An information item pointing to a metadata-only 
genericode file is unconstrained because there 
are no codes specified to constrain the edited 
value.  As a result, all of these references to 
metadata-only files end up being ignored in the 
UBL 2.0 defaultcodelist.xsl validation step, as they should.

But they clutter up the cl/gc/default 
directory.  But they belonged there because of 
the <LocationURI> element in the metadata pointed 
to that default directory for all non-supplementary component code lists.

Oh, that brings up another distinction that was 
unclear in the UBL 2.0 code list 
directories:  the "cl/gc/cefact" directory is 
poorly named because these are the code lists 
that govern CCTS supplementary components, not 
the code lists that are from UN/CEFACT (because 
in the "cl/gc/default" directory there is, for 
example, the payment means code list from 
UN/CEFACT).  The SGTG proposal abandons this and 
puts all code lists in the "cl/gc/default" directory.

So we need to rethink the contents of and 
breakdown of files and directories in the UBL 2.1 
distribution to make more overall sense to users.

I think we need to consider:

   1) - distinguishing genericode files we write for code lists sourced from
        UN/CEFACT (not just those used in supplementary components); and in
        future deliveries (unless ICG gets their act together soon with some
        genericode 1.0 files for code lists) we can use this directory for
        the genericode files they publish rather than the ones we publish for
        our use of their codes
      - is this a useful distinction?  the current SGTG proposal doesn't make
        this distinction, so does it add anything for the user looking for
        code list files (perhaps not since they probably don't know which files
        are from UN/CEFACT and which are not)

   2) - distinguishing metadata-only genericode 
files from genericode files that
        actually have codes in them
      - these might be considered "template" genericode files but more
        accurately are just genericode files with only metadata and no codes
      - I'm questioning the utility of these templates as anyone could use
        an existing genericode file as a template, and does it make sense
        to have a file that doesn't contribute to the validation process?

   3) - reducing the CVA file as prototyped in 
the SGTG proposal to only specify
        those code lists with codes and not to specify the metadata-only
        genericode files since (a) they don't participate in validation and
        (b) they don't leave the impression to the reader of the CVA file that
        an information item is qualified when, at the end of the day, it is
        not qualified.

Thanks for your thoughts on this on the UBL TC 
list, plus we can discuss these items at the next teleconference.

. . . . . . . . . Ken

p.s. I think my own preferences for answers to 
the above questions, as I'll bring up at the meeting, are:

   (1) *not* to distinguish in different 
directories genericode files for code lists of 
UN/CEFACT and code lists from other sources, just 
put all code lists that are in play in to the 
single proposed "cl/gc/default/" directory;
   (2) abandon "template" metadata-only 
genericode files since they don't add anything to 
the validation process and any other genericode 
file can be used as a template; and
   (3) remove references to metadata-only 
genericode files from the CVA file of qualified 
information items to remove the "clutter" and so 
that readers looking in the CVA file only see 
references to genericode files that actually have 
codes (thus quickly being able to tell which are 
bona fide qualifications rather than placebo qualifications).

--
In-depth XSLT/XQuery hands-on training - Oakland/CA/USA 2009-08-03
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal