OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl-lcsc] Draft of code list paper, revised after face to face

In rationalising the work of the Library Content team to populate the code lists and correcting the CCT/Data Types schemas used in 1.0-Beta, we have encountered some issues with the Code List Representation paper.

Specifically, section 3 (Data and Metadata Model for Code Lists) - does not describe the CCTS (and therefore UBL) model for code types.  

Please find attached the correct description of the Code Type data model.

Unfortunately this confusion has a knock-on affect for both the samples and the XML Schema representation described in section 4.  Some components you use are not in the model and others that are in the model are not used.  We need someone to go over this before we can get a clear understanding of what the final schemas are supposed to look like.

it may assist you to have some sample data , so I am also enclosing the current (draft) specialised data type model for code types used in UBL 1.0

Burnsmarty@aol.com wrote:
I have revised the code list design document based on the results of the face to face. The specific goal of this exercise was to facilitate implementation of schemas based on the results of the face to face. Specifically, the model was modified to explicitly show how to use an extendable code list as one or more attributes of a component element. Tests were done to verify that the "choice 4" solution discussed at the meeting (see Ken Holman emails) would work and be parsable by at least one XML schema parser/validator -- XMLSpy 2004).
Specifically I have done the following:
1) Added additional new requirements
2) Appologies -- did not yet integrate Eve's valuable comments on requirements from last week.
3) Added explicit support for code values as attribute of component type. Verified that qualification of attribute can be independent of containing element, opening way for the "solution 4" approach in UBL <future>.
4) Qualified requirements as to (FUTURE) when section 4 does not yet support them by agreement at the face to face.
The attached zip file contains two versions. One normal version and one with revisions showing from the previous draft. Don't have pdf generator with me (I'm on the road). Will try to call in to conference on Wednesday to discuss.
All the best,

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.

tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]