Re: [ubl-lcsc] Code sets for Document and LineItem Status

[Anne Hendry <anne.hendry@sun.com>]

Regarding the use of numeric codes, there are two flavors I see here.
One is how ISO provides numeric codes for currency along with equvalent
alpha codes.  Here, both the codes are contained within the column called
'code'.  So this is a case where there are clearly two representations
of the same codes - one alpha the other numeric.

However, the UNECE / UNCL codes have only a numeric code.  The
associated words and phrases are not categorized as part of the "Code",
but rather as the "Value" of the Code.  It's a little unclear in their
format (eg. www.unece.org/trade/untdid/d03a/tred/tred1229.htm) whether
the values were intended to be used as codes, or more for descriptive/
documentative purposes.  Particularly since some of them are almost
complete sentences, and there is no distinction made between single-word
'Values', or longer descriptive 'Values'.  But it doesn't seem as though
the Value is intended to be considered the Code.  In the currency table
it is clear that the mnemic is also considered a code, but not in these
uncl/unece code lists we're looking at.  I'm not sure if we should take
any significance from this distinction, though.  It would be helpful
to know how these are used today in other implementations (whether the
numeric code is only used, or if theEnglish-word values are used instead.
Because somewhere along the way there will need to be some mapping,
and the side that is recieiving the code would want to know if it is
receiving an alpha stirng, or a number that needs to be mapped to an
alpha string.

jon.bosak@sun.com wrote:

>The suggestion to use numeric codes is interesting but doesn't
>really solve the problem.  The problem is that mnemonic codes are
>troublesome and represent a significant investment of intellectual
>effort.  Numeric codes eliminate this effort by abandoning the
>goal of easy recognition by some large body of users.  Numeric
>codes are, in short, an admission of defeat.  Maybe in the end
>that turns out the best we can do, but I'm not yet ready to throw
>in the towel without considering a couple of obvious alternatives.
>
>I will note in passing that the numeric version of a list is
>actually an entirely separate code whose members just happen to
>map to the same referents.  I don't see a technical difference
>between a numeric code list packaged with the alphabetic version
>by ISO and a numeric code list developed by some separate agency
>with a mandate to resolve its list to the same values.  (Hmmm.)  I
>think this means that the alpha and numeric versions of a standard
>that provides both have to be modeled as structurally distinct
>lists, and users are going to have to explicitly agree on which of
>these they are using, just as they would if the lists were
>maintained by separate agencies.  Thus it is demonstrated that in
>talking about alternatives, we are not in danger of losing the
>purity of a single code list for each application; the standards
>bodies themselves have already done that by providing officially
>sanctioned, logically distinct variants.  They already require
>users to choose among alternatives and convey that decision to
>their trading partners.
>  
>

Yes, it seems to me the 'based on' approach is the most flexible.

>>Fortunately, I think we have some flexibility here.  With these
>>EDIFACT codes, we can be 'based upon' .  So a middle ground would
>>be to use the 'short description' e.g. the words
>>"Accepted","Conditionally Accepted" and "Rejected".  I think this
>>is better than inventing our own terms.
>>    
>>
>
>Maybe not that algorithm, precisely, but something like that.  It
>should be remembered that no one can copyright an idea, only its
>form of expression.  There's nothing private about the semantics
>of these code lists; their meanings belong to everyone.
>
>Perhaps this is something that someone could take on over the
>winter break.  How many elements, roughly, would we guess are
>contained in the standard lists that we've identified as basic to
>UBL operation (aside from the two that we believe we've been
>licensed to use by ISO)?  What's the size of this task, really?
>

The ISO LOCODES are quite large.  The one with the most values
that we are flirting with is the ISO 'Location' (cities) list which
is about 36000 entries, and the 'Subdivision' (states/provinces/etc)
list, which is obviously smaller, but still quite large.  We don't
seem to be using a code for cities at the moment, so we may not
need to utilize that larger 'location' code list, but there is
a UBL CountrySubentityCode that could utilize the ISO 'Subdivision'
code list.  We have a LocaleCode, which may be large, depending on
what it refers to - language locales or place locales.

But the other codes we're looking at are mostly under 100 items
and often only a dozen or so if that (eg. HazardousPackingCriteriaCode
(UNCL 8339) has 3 - (1) Great Danger, (2) Medium Danger, (3) Minor Danger;
InhalationToxicityZoneCode has 4 - Hazard Zones A, B, C, and D (and 
maybe E).
This is what many of the others look like.  The quantity of code values
is not high, but the quantity of code lists themselves that need to be
sorted through to find the 'right' one - this is the major time sync.
Once the codes are identified there's not much to implementing what we
need (other than  for the location codes just mentioned above).

However, I thought we were only considering including some, not all,
of the values that were 'based on' or 'aligned with' these standard
codes (the ones Stephen has listed).  That seems to be a rational
approach that would keep the task manageable.

-A