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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: RE: PartyId and Context


I'm not sure I completely understand. 

All I'm talking about is **identification** schemes, not classification
schemes. The issue is, as you correctly say, we need a mechanism to
effectively govern the IDENTIFICATION_SCHEME values so they are also unique
and meaningful.

Am I right in thinking that the CLASSIFICATION_SCHEME and instance of a
value in that scheme then becomes something that describes what is being
identified, e.g. a NAICS code of "541511" could classify a company with a
DUNS number of "126000798".

If my understanding is correct then I would like your suggestions on how to
create a mechanism for the IDENTIFICATION_SCHEME.

My suggestion was that by using a URI, or a URN, anyone who wants to set up
a scheme of numbers to work with ebXML will just need to register with IANA
first ... and that is all. For example D&B could register DUNS.COM, IATA
could register IATA.ORG, or whatever. We then immediately have uniqueness
and interoperability. 

If we don't use IANA for this, then we **MUST** come up with a viable
alternative. What are your suggestions?


-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Friday, December 15, 2000 2:41 PM
To: Burdett, David
Cc: Christopher Ferris; Scott Hinkelman; Charlie Fineman;
ebxml-tp@lists.ebxml.org; ebxml-transport@lists.ebxml.org;
ebXML-Architecture List
Subject: Re: PartyId and Context

"Burdett, David" wrote:
> What I propose is that we allow both example 2 and 3. Specifically:
> 1. If no usercontext is present then the content of the From (or To) must
> a URI.
> 2. If usercontext is present then the recipients of the message must be
> to unambiguously determine who sent the message by methods mutually
> Does this make sense?


This is very similar to problems that other areas of ebXML are trying to
solve.  I am generally in agreement with your ideas but I think we
should require an explicit qualifier for URI's.

If I may ->  let's summarize what we are trying to do.  We need to have
a "UNIQUE_VALUE" and a context.  The context is really a
"CLASSIFICATION_SCHEME" (Like DUNS).  What we also need is a mechanism
to effectively govern the CLASSIFICATION_SCHEME values so they are also
unique and meaningful.  

The CLASSIFCATION_SCHEME needs to be recognized.  It also has to
facilitate extensibility by those using it.  Here are some examples that
XML Global has used for it's ebXML POC:

For Companies:


Tax Number

Here is an example of some XML that MAY be in a CPP:

           <!--First section deals with how to classify a Company.  For
               information on NAICS see
           <classification Scheme="NAICS" value="541511">
              <description xml:lang="EN">Custom Computer Programming
              <description xml:lang="FR">Services Faits sur commande De
           <!--allow multiple classifications-->
           <classification Scheme="NAICS" value="511210">
              <description xml:lang="EN">Computer Software
           <identification Scheme="DUNS" value="126000798"/>
           <identification Scheme="REVCAN" value="870693157 RM0001"/>
           <identification Scheme="US EIN" value="84-1434313"/>
           <classification Scheme="SICS" value="7372"/>
Your proposal is to allow URI's.  If this was acceptable,  I think the
syntax should be:

<identification Scheme="URI" value="some_URI"/>

This uses the same mechanism, which you have described to both classify
AND identify companies.  We can also extend the same mechanism to
classify and identify products:

      <classification Scheme="UNSPSC" value="43161501">
        <description xml:lang="EN">XStream: XML Globals' new Native XML

In short, I do not like the idea of URI's becuase they are not stable
enough, however, there are those who may disagree.  If we do allow
them,  the URI should be explicitly classified using a syntax similar to
the previous examples.

The second bit we need to concern ourselves with is who or what
mechanism keeps the master list of the CLASSIFICATION_SCHEMEs that are
available to use.  

This is a hard question to pose.  The answer must specify a mechanism
that is secure, extensible, easily accessible, contains sufficient
explanations to allow people to decide which ones to use, is global (ie
- no "North American" only solutions), must be location independant
(NAPTR?), etc.

Duane Nickull

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC