Re: [codelist] New feature request for genericode 2.0

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2009-04-26 22:06 +0100, Anthony B. Coates (DES) wrote:
>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).

Yes, that is it exactly.

For each of the UN/CEFACT supplementary components, the listID= 
attribute is the one that has no corollary in genericode, other than 
it is a long name just as the title is a long name.

But every user of UN/CEFACT supplementary components who looks to 
genericode without looking at the decision made by UBL will make a 
different choice of @Identifier attribute to use for the listID= attribute.

That is what worries me ... multiple uses of genericode for UN/CEFACT 
and they don't interoperate.  I cannot pick up and use a genericode 
file written by someone else for a UN/CEFACT list if they chose a 
different Identifier= to identify this UN/CEFACT construct.

>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.

I can understand that.

>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.

Fine then.

>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.

Except that more users of instance-level meta data in supplementary 
components will be using listID= rather than

>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.

And I'll take that.

Should there, then, be an informative annex in genericode with 
"suggested" values for Identifier= attributes?  So that when other 
users of genericode choose to map to UN/CEFACT supplementary 
components, the same conventions will be used?  For completeness, 
that annex could list all of the UN/CEFACT supplementary components 
and document what the CLRTC offers as mappings to genericode.

But could we consider having:  <ShortName>, <LongName> and 
<Identifier> in <Identification>?  Then it wouldn't be a problem for 
UN/CEFACT components.  That choice of three elements is already made 
for <Agency>, rather than one short and two long names for <Agency>, 
so there is a precedent of having sibling <LongName> and <Identifier> elements.

. . . . . . . . . . . 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