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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl] More code list questions about NDR, and about genericode


At 2005-11-06 10:54 +0000, Anthony B. Coates wrote:
>On Sun, 06 Nov 2005 00:09:10 -0000, G. Ken Holman
><gkholman@CraneSoftwrights.com> wrote:
>
>>>There is a piece of work to do around producing matching information
>>>for each code list.  It may exist in the spreadsheets (???), but the
>>>question will be how best to get it into the genericode XML.
>>
>>I'm not sure what you mean by "matching".
>
>I meant it in the non-technical sense.  I was thinking that if the UBL 1.0
>code lists didn't have the necessary values in them, we would need to get
>them from somewhere.

Indeed.

>However, I just had a quick look, and the code list
>Schemas do appear to have these values, e.g.
>
><xsd:attribute name="codeListID" fixed="ISO3166-1" .../>
><xsd:attribute name="codeListAgencyID" fixed="6" .../>
><xsd:attribute name="codeListAgencyName" fixed="United Nations Economic
>Commission for Europe" .../>
><xsd:attribute name="codeListName" fixed="Country" .../>
><xsd:attribute name="codeListVersionID" fixed="0.3" .../>
><xsd:attribute name="codeListURI"
>fixed="http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1-semic.txt"; 
>
>.../>
><xsd:attribute name="codeListSchemeURI"
>fixed="urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-1.0" 
>
>.../>
>
>Aren't the 'fixed' values here the ones that we need, or have I completely
>missed something?

Oh, the XSD files do have them, but I'm working from the genericode 
files created from the XSD files using your scripts.  I understood my 
focus to be the genericode files and not the XSD files.

>Probably the latter, but I admit to being a bit lost.

I am probably the lost leading the lost, then ...

My understanding was that using your XSD to genericode scripts I 
would demonstrate the use of a UBL 1.0 CD 2 scenario having created 
genericode files from XSD files:  trading partners would edit the 
genericode files to the set of values desired in their transactions, 
engage those edited genericode files with my genericode to SCH 
scripts, and then value-validate their instances using Schematron.

Perhaps if you could modify your "XSD to genericode" scripts for UBL 
1.0 CD 2 to place the list metadata values in the genericode instance 
for me to pull out into my Schematron assertions, then I could 
demonstrate the entire process that trading partners would go 
through.  Since your demonstration ZIP only had a single code list in 
it, I was going to use your script to transform all of the code lists 
from UBL 1.0 CD 2.

For demonstration purposes I thought we'd package up my scenario for 
UBL 1.0 CD 2 (when I finally finish the darn thing!) and post it to 
UBL-dev for feedback so that we would have some comments to consider 
when creating the same for UBL 2.0.

All along I've seen your genericode files as the bridge between the 
XSD expressions and what trading partners need to agree upon.

Alternatively, we just leave status quo for UBL 1.0 CD 2 and I 
demonstrate value checking without metadata checking, just so I can 
progress the demonstration, and then we revisit all this to do it for 
the UBL 2.0 XSD files.

Another alternative would be for you to generate all of the 
genericode files for me for the code lists for my demonstration and 
I'll just work from those ... would we be publishing the genericode 
files as part of the UBL supplemental information release?  If so, 
then I (and trading partners) don't need the "UBL to genericode" 
scripts, as the genericode files will be readily available for 
trading partners to use.

Personally, I would like to see the UBL committee publish the 
genericode files as artifacts in the supplemental package.  Give 
those files first-class status.  Then my "edited genericode to SCH" 
process documents what trading partners do to take advantage of these 
artifacts they find.  I think that is better than asking trading 
partners to generate the genericode files from the code list XSD 
files ... since that is a fixed process and something that can be 
done ahead of time for all UBL users.  Translating genericode files 
to SCH files is not something we can do ahead of time because trading 
partners need to edit the genericode files to include the values they want.

I would see in the supplemental information package a directory of 
genericode files, one for each of the code lists of both "type 1" and 
"type 2", and then my discourse on how to use supplied XSLT scripts 
after editing the genericode files as agreed upon between trading partners.

But I'm open to doing it differently ... members are welcome to point 
me in a better direction ....

Thanks, Tony!  Let me know what you would like me to do.

. . . . . . . . . Ken


--
Upcoming XSLT/XSL-FO hands-on courses:  Denver,CO March 13-17,2006
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  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]