[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] Party Details
Duane Nickull asks: "The schema declares no enumerated list for values of the tp:type attribute so how can we reliably count on this ID as being unique, recognizable (semantically meaningful too) and easy to acquire and depend on?" Dale Moberg> I agree with Duane that it would be good if we had an enumerated list, with option to extend it. It would be good if these list values were at least standardized to URIs, probably URNs. But last time I checked, there was little agreement even on how to get an official URN for DUNS or whether it might need to get some official (read legal) approval to use it. Do you have some candidate values that could help standardization in this area? I am not an expert on these identifiers, or what we could use as enumerated values; Mr. Kammerer,however, who I know is an expert on these matters and others, possibly could provide us with a list of all commonly used identifier schemes. We might then use an oasis urn prefix to rig up enumerated values. But we need to act quickly. DN> 2. The PartyRef link is still an HTML link. I have raised this as an issue before. Yes. I prefer building an infrastructure that can rely on automated or partially automated processes to help suggest designs for business collaborations, it is essential that an application can read and understand the details of the PartyRef. DM> I agree with your preference. Duane>"Why? The information used for the COntext drivers can only be learned from this information. It is not always guaranteed that it will be there in the RIM metadata. There are several context drivers that will depend on this information to build the final CRM (context Rules Message), most notibly "geopolitical" which also controls government restrictions (I'm talking about stuff similar to how hard it is for you Americans to buy Cuban Cigars). DM> Yes, we discussed this in Vienna, I recall, and introduced the "type" value discussed above to meet your concern. Duane> "I suggest that you have a way to tell the one activating the xlink what format the information is in. Can we do something like this: "<tp:PartyRef tp:format="eCo.dtd" xlink:href="http://CompanyA.com/CompanyAeCo.xml"/> "The format attribute could be enumerated types of known XML based information to allow another application to recognize and parse it as such. DM> Still need the standardization for the format field values. Also, wouldn't it be possible to use declarations or namespace info after dereferencing the URL to GET the data, whether you had handlers to find the right elements/attributes? If the format value adds something beyond this, the group can take this up. Please provide a few words in defense here, however. Duane>Such formats could include the XAL and XNL work from OASIS, eCo from CommerceNet and any other XML address format that may be useful to include. DM>OK, do these have standard identifiers at present? YOu could still have plain ole' HTML too. DM> Yup.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC