Copyright © 2003 OASIS
$Date: 2003/08/29 14:36:48 $(UTC)
Table of Contents
In attendance were Anne Hendry, Tony Coates, Steve Green, Jon Bosak and G. Ken Holman (chair).
The minutes of the last meeting are posted at:
There were no comments on these.
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:
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.
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
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.
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).
20030814-Action1 - Tony - supplemental file approach summary
summarize the approach and justification of capturing supplemental information in an adjunct file separate from the W3C Schema expression used for validation
http://lists.oasis-open.org/archives/ubl-lcsc/200308/msg00028.html
disposition:
would all members please review this for the next meeting
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
http://lists.oasis-open.org/archives/ubl-lcsc/200308/msg00055.html
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
20030828-Agenda1 - address Chee-Kai's concerns
Chee-Kai has expressed concerns about not using <xsd:appinfo> with very similar arguments as were brought up in face-to-face discussions in Montréal:
Steven, Mark and Ken have tried to address those concerns in follow-up posts on the thread, the latest post being:
disposition:
we will await a response from Chee-Kai that we have allayed his concerns and that we have been able to convince him of the decisions we have made regarding not using <xsd:app-info>
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
A review of all action items both from before the meeting and established during the meeting.
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]
Many thanks to Anne for her transcription of the discussion from which these minutes were embellished.