ebxml-architecture message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: PartyId and Context




"Burdett, David" wrote:
> 
>
> SUMMARY
> 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 be
> a URI.
> 2. If usercontext is present then the recipients of the message must be able
> to unambiguously determine who sent the message by methods mutually agreed.
> 
> Does this make sense?
>...>>>>>>

David:

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:

Classifiers:
NAICS
SICS

Identifiers:
DUNS
Tax Number
URI's

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

**************************
<companyProfile>
           <!--First section deals with how to classify a Company.  For
more 
               information on NAICS see
"http://www.census.gov/epcd/ec97brdg/"-->
           
           <classification Scheme="NAICS" value="541511">
              <description xml:lang="EN">Custom Computer Programming
Services</description>
              <description xml:lang="FR">Services Faits sur commande De
Programmation                                         
D'Ordinateur</description>
           </classification>
           <!--allow multiple classifications-->
           <classification Scheme="NAICS" value="511210">
              <description xml:lang="EN">Computer Software
Publisher</description>
           </classification>
           <identification Scheme="DUNS" value="126000798"/>
           <identification Scheme="REVCAN" value="870693157 RM0001"/>
           <identification Scheme="US EIN" value="84-1434313"/>
           <classification Scheme="SICS" value="7372"/>
</companyProfile>
********************************
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:

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

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]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC