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

maybe i did not make this clear enough.

1.  there is not such thing as "listAgencySchemeID" and "listAgencySchemeAgencyID" - nor any equiavlent.  The nearest is perhaps "CodeListSchemeURI", but i am not sure that would support your examples.  I dont think we can have a managing agency as you describe.  what we are doing in 1.0 is simply having the managing agency as CodeListAgencyID and using the CodeListID and CodeListName to imply other authorship  So we have "ISO4127 Alpha" as the "CodeListID" and "6" as the CodeListAgencyID ("6" being UN/ECE).

2. the mapping in table 4-2 are now incorrect and therefore all the names in the data model mapping.  in particular the thing called "Code. Name" is not the name of the code.  it is the descriptive form of the code value.  so if the Code. Content = "1", the Code. Name may = "Original", if Code. Content = "2", then Code .Name may = "Replacement", etc..  The name of a code list is  Code List. Name. Text ( or in UBL this is "CodeListName", expressed as the attribute "codeListName").
This and most other UBL names need to be corrected throughout this section.

PS, I also forgot to update the table in 3-2 with the UBL abbreviation for Uniform Resource Identifier (URI). So what was "CodeListUniformResourceID" is now "CodeListURI" and what was "CodeListSchemeUniformResourceID" is now "CodeListSchemeURI".

please find attached an update to my previous update :-[

Burnsmarty@aol.com wrote:
Thanks so much for taking a close look at this and making your contribution of a corrected and fully populated data model.
I have taken a quick pass through merging your changes and aligning the XMLSchema representations accordingly. I am certain that this is only an approximate result.
I would suggest, if possible, that the CLSC team at today's conference call identify any remaining gross errors and divide up the sections in 3 and up to but not including 4.9. If we break it up into small chunks, the QC process should not take anyone too long.
This will leave for me to merge Eve's comments on the requirements, and, an editing of the section 4.9...

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]