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