OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

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


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>


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


Powered by eList eXpress LLC