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] Fwd: ICG report from Rome

as an EDI user I find the <CodeListSet> just a way to have a unique file
to download, because the codelists should be decoupled by the message and
the from the CEFACT Directory too.  What I mean is I think very difficult
there will be interopeability by stating to use a precise <CodeListSet>

Code lists like UN/LOCODE and others are required to be updated more
frequently respect to what CEFACT does.

Maybe there should be an effort to standardize the way to discover new
codelists and their version online.

The "Directory" packaging available on CEFACT is not good for codelists.

Codelists should be updated separately from messages.

By the software development point of view a unique set will complicate and
delay the adoption, as the Genericode is designed as a mean of transport
and exchange, but it is not strictly designed for implementation.

From an XSD it is more easy to have a reference URI to a single precise

A single set again, will be a huge file, forcing developers and users to
use more RAM and change default HEAP Memory settings on most common tools
and languages.

I agree with Ken a ZIP is more pratical :)

"Pens are not working on the moon, we must use a pencil"

Cheers Roberto.

> At 2009-05-13 19:15 +0100, Anthony B. Coates (DES) wrote:
>>the genericode 2.0
>>proposal that I recently sent to the CLRTC list included the changes that
>>they need to support this.  So, if everyone is happy with what I sent, I
>>now have to get cracking with updating the specification document to
> I can understand <CodeListSet> might be useful for transporting a set
> of code lists which is then burst into independent code lists on
> receipt.  But I have questions regarding any use-case for reaching in
> to a <CodeListSet> to work with the code lists that are found.  I'm
> trying to determine what code changes and spec changes this might
> have on a CVA file when the user wants to point to a code list found
> inside a code list set.
> Are there any uniqueness constraints on <Identification><ShortName>
> in a set of code lists?
> If I am given a code list set and two code lists in that set satisfy
> my identification criteria, do both somehow apply?  Perhaps only the
> first?  Is it left up to users?
> If it is left up to users, why bother standardizing the concept of a
> set and the implications it has on the markup?  If it is only for
> transporting a collection of code lists, then just ZIP up individual
> files so they can each have their own ID-value-space and can be
> easily burst on receipt.
> I noted in the example all-cats-and-dogs-set-inline.gc how awkward it
> might become to guarantee uniqueness for all of the column
> identifiers.  One ends up divining a naming scheme to uniquefy the
> column identifiers.  And, should I make a typographical error on an
> IDREF that just happens to point to a column definition in another
> code list that this would pass XSD validation.  If the lists were
> independent as would be true after bursting, such a typo would be
> caught because the ID-value-spaces are independent (though, of
> course, it wouldn't catch pointing incorrectly to, say, a key
> definition instead of a column definition).  But if I'm supposed to
> access code lists sitting inside a set, user error could easily be
> pointing outside of one set into the information of another set.  My
> earlier post presented a situation where this is explicitly allowed
> and encouraged, but what I'm speaking of here is inadvertent.
> Consider that there is a <CodeListSet> at a URL ... does it make
> sense to define a mechanism by which "#" would address one of the
> lists in the set?  In a CVA file, the genericode file of a single
> code list is pointed to by a URI.  Traditionally, I suppose a URI
> with a local identifier would be to some kind of ID value
> guaranteeing uniqueness (though of course that is never guaranteed in
> an HTML document).  Since ID values are used for column
> specification, would the short name be used instead?
>     http://www.example.com/gc/lists/mySet.gc#Country
> ... where there is a list in the set with
> <ShortName>Country</ShortName>.  But this seems fragile.
> Thanks for your guidance on these issues.
> . . . . . . . . . . . Ken
> --
> XSLT/XQuery/XSL-FO hands-on training - Los Angeles, USA 2009-06-08
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> 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
> 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

* JAVEST by Roberto Cisternino
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor

  Roberto Cisternino

  mobile: +39 328 2148123
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]

[UBL Online Community]

[UBL International Conferences]

[UBL Italian Localization Subcommittee]

[Iniziativa divulgativa UBL Italia]

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