Re: [ubl-comment] UBL comments on ebXML Core ComponentsTechnicalSpecification v1.8

[Philip Goatly <philip.goatly@bolero.net>]

Hi Folks,
   I go with Ron on this one - a code is looked up in a table an Identifier
just is a way of idnetifying something.

Cheers, Phil

----- Original Message -----
From: "Schuldt, Ron L" <ron.l.schuldt@lmco.com>
To: "'Eve L. Maler'" <eve.maler@sun.com>; "Schuldt, Ron L"
<ron.l.schuldt@lmco.com>
Cc: <ubl-comment@lists.oasis-open.org>
Sent: Monday, April 29, 2002 5:57 PM
Subject: RE: [ubl-comment] UBL comments on ebXML Core Components
TechnicalSpecification v1.8


> A code is a code since the processor needs to refer to a look-up table to
> convert it to its value. An identifier contains the value between the
start
> tag and the end tag.
>
> The difference is in the behavior of the data and what the processor does
> with the data. Therefore, I must disagree with the notion that a code
could
> play the role of an identifier. I know that X12 has failed to use the
notion
> of identifier since the term "code" is used (and mis-used) extensively and
> in some instances should instead be using the term "identifier." In
general,
> where X12 uses the term "number" it can usually be interpreted as an
> identifier. For example, "communications number" - Data Element 364 in
X12 -
> would become "communications identifier" NOT "communications code"
>
> Ronald L. Schuldt
> Senior Staff Systems Architect
> Lockheed Martin Enterprise Information Systems
> 11757 W. Ken Caryl Ave. #F521 MP DC5694
> Littleton, CO 80127
> 303-977-1414
> ron.l.schuldt@lmco.com
>
>
> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Monday, April 29, 2002 10:37 AM
> To: Schuldt, Ron L
> Cc: ubl-comment@lists.oasis-open.org
> Subject: Re: [ubl-comment] UBL comments on ebXML Core Components
> Technical Specification v1.8
>
>
> Ron,
>
> You're right that codes get mapped to meanings, and that identifiers
> convey uniqueness.  But I think the proposal as stated is defensible.
> For example, it makes the point that sometimes codes can "play the role"
> of an identifier (that is, sometimes you have a piece of information
> that both can be mapped to a meaning and, when used on a particular
> object, indicates uniqueness of that object).  So making them be a
> mutually exclusive choice is unhelpful.
>
> The suggestion in the proposal is to allow identifiers to be
> *represented* in a variety of ways (at the RT level, e.g. as Codes or
> Names), while allowing the identifier-ness to be captured slightly
> higher up (at the property level).  So nothing is being lost.
>
> Eve
>
> Schuldt, Ron L wrote:
> > UBL Team,
> >
> > I concur with most of the comments contained in the document prepared by
> the
> > UBL team. However, the subject of CODE versus IDENTIFIER is not being
> > portrayed properly.
> >
> > In the example for Country Code, AU represents Australia and the
processor
> > would need to refer to a look-up table to convert from "AU" to its
meaning
> -
> > namely "Australia"
> >
> > In comparison, an "Employee Identifier" could be something like
> > 123-45-6789 and the processor does not need to refer to a look-up table
> but
> > simply takes the value captured between the two tags e.g.,
> > <EmployeeIdentifier>123-45-6789</EmployeeIdentifier>. Except for
> validating
> > that the string has the right characteristics, the processor does not
> > necessarily need to refer to a look-up table. Typically an identifier is
a
> > "key" that is used to join two or more tables. Idntifiers are necessary
> keys
> > for topics such as Part Identifier, Person Identifier (since names
cannot
> be
> > considered unique), Enterprise Identifier (typically assigned by a
> > registration authority such as DUNS), Engineering Drawing Document
> > Identifier, etc. In general, identifiers are used when when the
population
> > of the set is continually growing and some activity or system is
> continually
> > adding new identifiers.
> >
> > To simplify the difference, a CODE requires a processor to refer to a
> > look-up table to convert to the actual instance whereas an IDENTIFIER
does
> > not require the processor to refer to a look-up table but rather
captures
> > the instance value contained between the start tag and the end tag.
> >
> > Therefore, I strongly recommend that Proposal 9 be deleted or at least
> > revised to instead request further clarification of the differences. If
> you
> > concur with my examples above, perhaps they could frame a proposed
> > clarification.
> >
> > Ronald L. Schuldt
> > Senior Staff Systems Architect
> > Lockheed Martin Enterprise Information Systems
> > 11757 W. Ken Caryl Ave. #F521 MP DC5694
> > Littleton, CO 80127
> > 303-977-1414
> > ron.l.schuldt@lmco.com
> --
> Eve Maler                                    +1 781 442 3190
> Sun Microsystems XML Technology Center   eve.maler @ sun.com
>
>
> ----------------------------------------------------------------
> 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>
>


_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service.