[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: PartyId and Context
Duane 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? David -----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: > > > 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] | [Elist Home]
Powered by eList eXpress LLC