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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[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