[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Concept of code list templates for UBL 2.1
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]