Code list task group - Minutes 20030828 - 15:00UTC (11:00EDT/08:00PDT) - DRAFT

$Date: 2003/08/29 14:36:48 $(UTC)

Table of Contents

1. Roll call and quorum
2. Agenda
3. Minutes of the last meeting
4. Reports of standing committees
4.1. Code list task group deliverables
4.2. NDR rules related to code lists
4.3. FPSC guidelines related to code list member supplemental information
4.4. Code list catalogue
5. Outstanding action items
6. Agenda items
7. Action items
8. Future meetings
9. Acknowledgements
10. Adjournment

1.  Roll call and quorum

In attendance were Anne Hendry, Tony Coates, Steve Green, Jon Bosak and G. Ken Holman (chair).

2.  Agenda

Nothing was explicitly added to the agenda at the beginning of the meeting.

3.  Minutes of the last meeting

The minutes of the last meeting are posted at:

There were no comments on these.

4.  Reports of standing committees

Although we have not yet established our task group equivalent to a standing committee, I can think of the following areas that should be standing items for review at each meeting:

4.1.  Code list task group deliverables

It was agreed that the following deliverables would be the work products of this task group:

  • a set of rules regarding the construction of code lists for validation purposes for NDR to include in their deliverables

  • a set of guidelines regarding the provision of supplemental information related to code list members for presentation purposes for FPSC to include in their deliverables

  • a catalogue of all code lists in UBL 1.0 and the fulfillment plans for each one

It was agreed the above items covered all of the issues in Jon's summary post:

The question arose regarding an ebXML registry of the code lists: who is going to be responsible for ensuring the code lists we produce are suitably registered? The disposition of this is that it is the responsibility of others in UBL (perhaps LCSC?) to register all of the components of UBL and that the code lists we produce would be in the list of components. Therefore, there is nothing explicit for the task group to handle in this area.

4.2.  NDR rules related to code lists

From the agenda:

  • According to Mark, our work is on the critical path to produce an NDR deliverable. How much of what we are going to decide is on that critical path? Who can undertake to maintain this document and keep on top of it to ensure it is delivered to NDR as soon as possible?

There was some common confusion regarding the separation of the two responsibilities of a code list: the validation of a coded value found in an instance, and the association of supplemental information for applications with the individual coded values. For this part of the agenda the discussion was repeatedly brought back to the focus of validation issues and rules for NDR to satisfy only the objectives of:

  • confirming the coded values used in an instance are correct

  • standardizing the mechanism by which a collection of supplemental information is identified

With regard to validation, a lengthy discussion concluded with the following main points being made:

  • code lists form such a critically important role in interoperability that users of UBL should be forced to recognize that certain ones exist and that these particular ones would typically need to modified in agreement with trading partners to fulfill basic interoperability requirements of electronic business

    • for example, there is a status code for which the values of "copy", "original" and "replacement" are such basic concepts in a transaction's interchange to be expressed that these should never change or be compromised through alternative values

    • providing a set of codes and ensuring these are validated for all users will promote interoperability of this basic semantic without burdening the users with the need to "turn it on" after getting UBL "out of the box"

  • there exists certain code lists that will not be of much use to many users of UBL, yet for a few users it is important that they do exist

    • for example, a code list of country codes is important to UBL users who transact business across borders but will be of no use whatsoever to UBL users operating entirely within their own borders

    • the burden for validation of coded values for these discretionary areas should be "opt-in" after getting UBL "out of the box" rather than the default for all users

Regarding the existing 0.8-family of UBL schemas, there is no validation going on at all and all code lists appear to be of a generic type of coded value without any content value checking other than its syntax.

In the end, the validation perspectives of four different kinds of code lists were distinguished for UBL:

  • "standard"

    • an important code list for interoperability; e.g.: status code

    • UBL will supply candidate values that should be sufficient to all users of UBL

    • the values used in instances will be validated against the supplied values and validating processors will correctly throw errors when invalid values are used

  • "placebo"

    • an identified code list whose values should be agreed upon between trading partners

    • UBL "out of the box" will not enforce any validation of the coded values in these code lists, and will so engage this by indicating the generic "normalized string" data type for fields in which these coded values belong

    • the values used in instances will only be validated as being a normalized string and validating processors will not be able to detect that a supplied normalized string is appropriate or not for the semantics of the transaction

    • applications working with the instances have the responsibility of validating any content found for these coded values

  • "stock"

    • a UBL-supplied collection of candidate values available to be used in place of "placebo" code lists

    • trading partners who agree to utilize the values supplied by UBL can choose to replace the "placebo" lists with these "stock" lists after getting UBL "out of the box"

  • "private-use"

    • trading partners should always have the ability to create and then utilize collections of coded values of their own choosing

    • "private-use" code lists can replace either "standard" code lists or "placebo" code lists supplied in UBL "out of the box"

    • trading partners can choose to implement validation of private code lists either in the schema expression or in their applications but must do so without impacting on any other code list used

Regarding validation, the following was noted that the schema expression of coded values for code lists:

  • "descriptive" or "meta data (data about data)" information meant for human consumption is to be kept in an <xsd:documentation> construct for the code list

  • such information may be rigorously structured though this is not meant to imply it is for programmatic access and, more specifically, that UBL will not rely on programmatic access to any such information

  • there are different ways to express in W3C Schema syntax the validation of the value found for a code list, notably including the following:

    • a list enumeration

      • descriptive information could be kept with individual coded value definitions

    • a regular expression

      • descriptive information cannot be kept with individual coded value definitions

      • any description of the coded values would necessarily be kept with the entire code list definition

  • it was agreed that <xsd:appinfo> is not to be utilized as there is no role for UBL application-oriented information to be kept with the schema validation expression

  • the above distinctions had been discussed in Montréal and it was observed that <xsd:appinfo> and <xsd:documentation> exist to distinguish information for applications from information for humans when people choose to put such information in a schema expression, but that the schema expression is solely for validation and is not the best place for application information and we should, therefore, choose not to put any information into the schema expression for application access

    • the history of this was eluded to in Montréal: document model expressions exist for validation purposes and when people are writing Document Type Definitions (DTD) the only documentary construct is the comment; some users of DTD expressions coerced non-validation-oriented application information into the document model; the distinction in W3C Schema accommodates the difference but does not change the belief by many that the model expression is not the home for application information unrelated to validation

    • it was noted that <xsd:appinfo> is the appropriate place for validation-oriented information targeted for validation applications, as in the example of using Schematron to express validation constraints that cannot be expressed in W3C Schema semantics

4.3.  FPSC guidelines related to code list member supplemental information

From the agenda:

  • Whatever we decide for the creation and maintenance of supplemental information, the guidelines will be an FPSC document.

  • At one point Dan thought he could undertake the maintenance of this document, but that hasn't been confirmed yet.

As noted in the earlier discussion, it was agreed that the schema expression of coded values for code lists is not the appropriate place to capture or maintain application information unrelated to validation, such as the presentation-oriented information of interest to FPSC.

Any relationship of a code list to an available adjunct file should be found in the UBL instance so that a processing application (such as a stylesheet) need not have access to the XSD files. This is consistent with existing stylesheet methodologies since stylesheet technologies work with well-formed XML only and consciously keep validation-related information away from the stylesheet writer.

Due to time constraints there was no opportunity to discuss any technical aspect of the use of external adjunct files, other than to agree that whatever mechanism is chosen should be applicable to all code lists and should have no impact on UBL should there be no adjunct information available for a code list.

4.4.  Code list catalogue

We need to catalogue and track the fulfillment of those code lists we decide to include in UBL 1.0:

Jon has brought our attention to an earlier post by Tim regarding categories:

Anne has very kindly offered to maintain this catalogue and throughout the meeting made note of the fields of information that need to be maintained for each code list. In particular, the following fields were mentioned as candidates:

  • name of code list

  • "standard" or "placebo"

  • if "placebo", will there be a "stock" list in the deliverable

  • UBL data type for the code list

  • UBL base data type from which the specific data type is derived (if the values are shared amongst many code lists)

  • person responsible for fulfillment

  • status

  • due date

  • UBL-supplied adjunct file from FPSC?

  • due date

It was decided that the code list task group is not responsible for creating the individual code lists, but only for cataloguing the needed code lists (for LCSC) and addressing the methodology of code lists covering validation (for NDR) and adjunct information (for FPSC).

5.  Outstanding action items

20030814-Action1 - Tony - supplemental file approach summary

20030814-Action2 - Gunther - namespace-based approach summary

  • summarize an approach and justification of using a namespace-based scheme for capturing information about a code list, rather than using attributes in a UBL instance


  • on a personal note, I think there is some confusion in my mind over Gunther's use of "supplementary information" and what we have been talking about for "supplemental information" for presentation purposes; I wonder if during the last teleconference there were others as confused as I was when this item was brought to our attention

  • disposition:

    • no-one present at the meeting was able to comment on Gunther's submission

    • it was thought from quick review that it was outside of the purview of the code list task group and more related to NDR since it is related to the mechanisms of validation

    • members are asked to review the submission and offer comments at the next meeting

6.  Agenda items

20030828-Agenda1 - address Chee-Kai's concerns

20030828-Agenda2 - supplemental non-validation information

  • a technical discussion on issues of maintaining supplemental information useful for presentation and other non-validation-oriented purposes

  • disposition:

    • deferred

7.  Action items

A review of all action items both from before the meeting and established during the meeting.

8.  Future meetings

The next teleconference will be September 4, 2003. [a recent development while writing up the minutes: the chair is now unable to attend this meeting and someone will need to volunteer to take over; please let Ken know if you can do this]

9.  Acknowledgements

Many thanks to Anne for her transcription of the discussion from which these minutes were embellished.

10.  Adjournment

The meeting lasted a full two hours.