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
Powered by
eList eXpress LLC