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

 


Help: OASIS Mailing Lists Help | MarkMail Help

codelist message

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


Subject: Re: [codelist] New feature request for genericode 2.0


If I understand your meaning, Ken, you are suggesting standardised values  
for the "LongName/@Identifier" attribute (and if I don't understand your  
meaning, please reply and just ignore whatever I've written from here  
onwards).  I thought about this when I originally drafted together, and my  
thinking at the time is that you have to draw a line on identification  
somewhere.  I knew I could take it further, especially around types of  
long names, but I thought that it would be a diminishing return.

We could certainly propose some values for common purposes, a starting  
list that it not intended to be exhaustive, but I don't think it needs to  
be URNs, some plain old short token values would be sufficient, I would  
suggest.  When a code list is already identified by its canonical URIs as  
being a CEFACT list, I don't such a lot of extra gain in having a long  
name identifier that yet another CEFACT URI.

Additionally, I wasn't confident about being able to adequately pick the  
right set of long name identifier values, or even a good enough set, so I  
was prepared to let people be driven by common usage.  That was my  
personal thinking, anyway.

Cheers, Tony.

On Sat, 18 Apr 2009 18:41:23 +0100, G. Ken Holman  
<gkholman@cranesoftwrights.com> wrote:

> Looking at the list-level meta data in genericode, here is an example  
> from the UBL project:
>
> <gc:CodeList  
> xmlns:gc="http://docs.oasis-open.org/codelist/ns/genericode/1.0/";>
>     <Identification>
>        <ShortName>CurrencyCode</ShortName>
>        <LongName xml:lang="en">Currency</LongName>
>        <LongName Identifier="listID">ISO 4217 Alpha</LongName>
>        <Version>2001</Version>
>        <CanonicalUri>urn:un:unece:uncefact:codelist:specification:54217</CanonicalUri>
>        <CanonicalVersionUri>urn:un:unece:uncefact:codelist:specification:54217:2001-update</CanonicalVersionUri>
>        <LocationUri>http://docs.oasis-open.org/ubl/os-UBL-2.0-update/cl/gc/cefact/CurrencyCode-2.0.gc</LocationUri>
>        <Agency>
>           <LongName xml:lang="en">United Nations Economic Commission for  
> Europe</LongName>
>           <Identifier>6</Identifier>
>        </Agency>
>     </Identification>
>     ....
>
> Note the proper use in genericode of the LongName for different ways of  
> identifying the list.  Two ways of distinguishing the LongName are  
> shown:  a language description (using xml:lang=) and an identifier  
> identification (using Identifier=).
>
> Looking at the UN/CEFACT specification of unqualified data types, there  
> are two identifiers for code lists:
>
> http://docs.oasis-open.org/ubl/os-UBL-2.0-update/xsd/common/UnqualifiedDataTypeSchemaModule-2.0.xsd
>
>    <xsd:attribute name="listID" type="xsd:normalizedString"  
> use="optional">
>    ...
>    <xsd:attribute name="name" type="xsd:string" use="optional">
>
> I picked Identifier="listID" out of the air because it matches the  
> attribute name used by UN/CEFACT.
>
> The new "feature" I would like to discuss for consideration in  
> genericode is a standardized/recommended way of representing the  
> UN/CEFACT concept of a "list identifier".
>
> It might be a new <Identification> child element, but perhaps we just  
> document the use of the existing LongName element so that readers of the  
> specification have a guideline.
>
> Should we be using something like:
>
>    Identifier="urn:un:unece:uncefact:codelist:listID"
>
> ... but who are we to pick up the UN URN namespace and choose a value to  
> use?
>
> Maybe we should use:
>
> Identifier="urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2"
>
> ... which is the namespace of the unqualified schema fragment.
>
> Is this something that should be standardized/recommended by UN/CEFACT,  
> or something in the purview of our OASIS committee?
>
> Should we even say anything at all in the genericode specification, or  
> leave this up to users like the UBL committee?
>
> I'm curious to know your thoughts on this.
>
> . . . . . . . . . . .  Ken
>
> --
> XSLT/XQuery/XSL-FO hands-on training - Los Angeles, USA 2009-06-08
> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
> Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
> Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-- 
Anthony B. Coates
Associate Director
Document Engineering Services (Limited)
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Skype: abcoates
anthony.coates@documentengineeringservices.com
http://www.documentengineeringservices.com/


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