RE: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of Alpha-3 CodeElement for Romania]

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Mike:

The problem we ran into with xCBL (which had a stated goal of wanting to
support EDI use of codes) was "which set of codes?"

To simplify:

There are three types of codes:

(1) ISO code lists supported by everybody: ISO currency, language, locale
(often through the UN/ECE) - we used these as is. As you say, it's a "no
brainer." Complete agreement from me.
(2) X12 codes
(3) UN codes (from the codes working group)

There is a huge degree of overlap between 2 and 3, and sometimes the *same*
alphanumeric code represents different semantics in 2 and 3. This is very
confusing. Both are heavily used in business applications. SMEs cannot
afford the kind of tools that make this problem easily tractable.

What we did, to try to meet expectations of x12 users and UN/EDIFACT users,
was to compare the codelists from 2 and 3, identify the overlap, and then
come up with an "intuitive" single-word "code" that was mapped back to it's
sources (usually X12 and UN codes). Thus, we didn't have to answer "which
set of codes?" - we supported both without using either.

This is the kind of approach that I think UBL should also take, since it
provides support without inheriting the problems associated with making a
choice betwen 2 and 3.

Also, we will want to discuss how far we should go towards accomodating the
capabilities of legacy systems, since I don't think that this is a
show-stopping issue for people adopting a new vocabulary. Basically, what we
are telling them is that they have a new set of mapping tables, and the new
codelists use 9 characters instead of 3. (Or whatever constraints we choose
to put on the UBL codelists members).

While I agree with your basic practical approach to this, there are some
problems here that we will need to solve.

Cheers,

Arofan Gregory

-----Original Message-----
From: Mike Rawlins [mailto:mike@rawlinsecconsulting.com]
Sent: Monday, February 11, 2002 11:33 AM
To: NDR SC
Subject: Re: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of Alpha-3
CodeElement for Romania]


This discussion has hit enough different points that I'm somewhat unclear
about
the original point.  However, there have been a few things said that I find
somewhat discomforting or not on target.

May I offer a few "bottom-line" points regarding codes, representations, etc
:
Codes are generally used for dictates imposed by business applications, and
that
is where we really need to base our decisions.  If a code lists offers both
a
numeric representation and an alphanumeric one for the code value (there may
be
some, but I've never seen any that do), then we choose the one most used by
business applications.  That should be a no-brainer.

In addition, most code lists are neutral to spoken languages when we
consider
the code value (which is what appears in the datastream) and not the code
description.

I don't see the problem.  Is there something here I'm missing???

Cheers,

Mike

"Gregory, Arofan" wrote:

> Folks:
>
> I must point out that one of the things that has always struck me about
EDI
> was that, because non-intuitive alphanumeric "codes" were used to such a
> great extent, the language became arcane and subject to abuse. This leads
to
> expensive implementations.
>
> This is *not* a point about the separation of presentation and content,
> which can be achieved in any number of ways (at least two of which underly
> the current discussion, and I'm not sure they're compatible).
>
> I think we want to do a few simple things that EDI has failed to do with
> codes:
>
> (1) Present our semantics clearly: intuitive tag names with absolutely
clear
> definitions
> (2) Make sure that our "presentation" of code values has a simple default
> that doesn't rely on the implementer's interpretation of it
> (3) Make things human-readable where there is no good reason not to
>
> If we return to using alphanumeric codes to (supposedly) convey complex
> semantics, we have merely added a layer of obscurity that doesn't really
buy
> us very much.
>
> The point of separating content and presentation reads, to my way of
> thinking: "don't let presentation concerns cloud your semantic
definitions".
> I think that this is the heritage of XML, as I understand it. Having
> non-readable alphanumeric codes is a violation of this rule, to my way of
> thinking, and we should not go there unles it buys us something important.
>
> (All right, Phil: let's talk about compactness of expression now! However,
I
> will point you to the design principles around tag naming that Eve had us
> prioritize at the F2F...)
>
> Cheers,
>
> Arofan
>
> -----Original Message-----
> From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
> Sent: Monday, February 11, 2002 9:58 AM
> To: 'Eduardo Gutentag'; Phil Griffin
> Cc: NDR SC
> Subject: RE: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of Alpha-3 Code
> Element for Romania]
>
> Point taken Eduardo: there does seem to be wide consensus that separation
of
> model from presentation is a Good Thing.  That's why it's ironic that in
the
> XML community we're always talking about how our document instances should
> be "readable".  "Readablility" is a goodness measurement of "presentation"
> right?  A model wouldn't have to be readable right?
>
> There are a whole range of tradeoffs possible.  A presentation-free model
> exists at one end... pure presentation details is at the other. Inasmuch
as
> we've already chosen a midpoint, I see nothing absurd about discussing
> possible surrounding midpoints.  In order from presentation-free to
> presentation-full here are some points in the continuum (choices we could
> make for our document/message meta-structure):
>
> * a binary structure -- you've got to read the schema (not included) to
> understand the structure
> * a text-encoded structure that's fairly readable but which carries no
> "markup" save positional and nesting markup (think LISP S-EXPR's) --
you've
> still got to read a schema to know what's going on
> * some sub-XML type thing that's e.g. less verbose -- now you have "tags"
> but perhaps structure end is a generic close delimiter -- not a repeated
tag
> name.
> * XML -- now you've got tag names, but in what language -- you've already
> picked a presentation right?
> * XML with "human readable" code list values -- again, in what language
>
> If we're going to go for a clean separation of "model" from "presentation"
> the I'd guess that we'd want to e.g. use numbers to identify code list
> values in a language-neutral way.  That being said I find it a little bit
of
> a double standard, given that we've chosen XML as a basis (what with all
> it's redundancy-for-the-sake-of-readability)
>
> I just re-read Phil's message:
>
> > > The numeric representation of the country identifier
> > > is the only part that we rely on in canonical XML
> > > markup based on the ASN.1 schema. Only the numeric
> > > portion of an abstract value such as "ROM(642)"
> > > need ever appear in the transfer syntax where there
> > > is typically no human reader involved.
>
> I think the key word is "rely".  The way I would interpret this idea for
UBL
> would be that we would make the "pure identifier" (the numeric one)
> required, and we'd make the textual one ("ROU") optional.
>
> Seems like we ought to give some guidance that says: "A UBL-compliant
> processor will operate only on the pure identifiers -- not on the textual
> ones".  In what artifact could we make such a statement?  Is that part of
> our charter?  I think it should be.
>
> > -----Original Message-----
> > From: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com]
> > Sent: Monday, February 11, 2002 11:05 AM
> > To: Phil Griffin
> > Cc: NDR SC
> > Subject: Re: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of
> > Alpha-3 Code
> > Element for Romania]
> >
> >
> > The separation of content from presentation is fundamental to
> > how XML is supposed to work, either via stylesheets (preferrably)
> > or via the applications themselves.  So I'm not sure what
> > novelty you're proposing. I thought this was a given.
> >
> > Phil Griffin wrote:
> >
> > > FYI. This seems relevant to our work. And I believe
> > > illustrates just how subject to change character
> > > string code lists can be.
> > >
> > > I note that while the numbers are not as expressive
> > > perhaps for human readers, they are stable and work
> > > reliably in software.
> > >
> > > The numeric representation of the country identifier
> > > is the only part that we rely on in canonical XML
> > > markup based on the ASN.1 schema. Only the numeric
> > > portion of an abstract value such as "ROM(642)"
> > > need ever appear in the transfer syntax where there
> > > is typically no human reader involved.
> > >
> > > Perhaps we should consider that the characters to be
> > > displayed or read by an application could be disjoint
> > > from the value actually used for validation purposes.
> > >
> > > That is, I might send you 642 and you might choose to
> > > display "ROMANIA" or "ROM" or "ROU" or nothing based on
> > > you own local copy of the characters that map to these
> > > numeric values.
> > >
> > > Not a perfect solution, just an idea for consideration.
> > >
> > > Phil
> > >
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > Subject:
> > >
> > > Fwd: ISO 3166-1 -- Change of Alpha-3 Code Element for Romania
> > > From:
> > >
> > > Francois Vuilleumier <fvuille@attglobal.net>
> > > Date:
> > >
> > > Sun, 10 Feb 2002 18:38:08 +0100
> > > To:
> > >
> > > moumg@ties.itu.int
> > >
> > >
> > >> From: "Wischhoefer Cord" <wischhoefer@iso.org>
> > >> Subject: ISO 3166-1  --  Change of Alpha-3 Code Element for Romania
> > >> Date: Mon, 4 Feb 2002 10:58:28 +0100
> > >>
> > >> Dear All,
> > >>
> > >> For your information here's the latest on ISO 3166-1:
> > >>
> > >> On request of the Romanian Government the ISO 3166/MA decided to
> > >> change the ISO 3166-1 three-letter (alpha-3) code element
> > for Romania
> > >> from ROM to ROU.
> > >>
> > >> The two-letter code element RO remains unchanged.
> > >>
> > >> The change took effect on 1 February 2002.
> > >>
> > >> Below are the URLs of the two language versions of the ISO 3166-1
> > >> Newsletter V-3 announcing the change.
> > >>
> > >> English version of the Newsletter:
> > >> http://www.din.de/gremien/nas/nabd/iso3166ma/nl_pt1/nlv3e_rou.html
> > >> French version of the Newsletter:
> > >> http://www.din.de/gremien/nas/nabd/iso3166ma/nl_pt1/nlv3f_rou.html
> > >>
> > >> Best regards
> > >>
> > >> Cord Wischhöfer
> > >> ISO 3166/MA Secretary
> > >>
> > >> Tel.: +41 22 749 72 33
> > >> Fax: +41 22 749 73 49
> > >> Email: wischhoefer@iso.org <mailto:wischhoefer@iso.org>
> > >> <mailto:wischhoefer@iso.org>
> > >
> > > Part 1.2
> > >
> > > Content-Type:
> > >
> > > message/rfc822
> > >
> > >
> >
> >
> > --
> > Eduardo Gutentag               |         e-mail:
> > eduardo.gutentag@Sun.COM
> > XML Technology Center          |         Phone:  (510) 986-3651 x73651
> > Sun Microsystems Inc.          |
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>