[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] CPPA version 1.10
+1 Martin W Sachs wrote: > David, > > The problem with using type="DUNS" is that the values are arbitrary > character strings; something has to define values of the type attribute > that both parties understand. I don't know of any way other than > expressing them in the specification and putting a fixed enumeration in the > schema. With the URI approach there is at least a hope of obtaining the > type information from outside of the CPPA and MSG specifications and > schemas. > > Regards, > Marty > > ************************************************************************************* > > Martin W. Sachs > IBM T. J. Watson Research Center > P. O. B. 704 > Yorktown Hts, NY 10598 > 914-784-7287; IBM tie line 863-7287 > Notes address: Martin W Sachs/Watson/IBM > Internet address: mwsachs @ us.ibm.com > ************************************************************************************* > > > > "David Fischer" > <david@drummondgr To: "Christopher Ferris" <chris.ferris@sun.com>, "Dale Moberg" > oup.com> <dmoberg@cyclonecommerce.com> > cc: "Arvola Chan" <arvola@tibco.com>, "Duane Nickull" <duane@xmlglobal.com>, Martin W > 03/21/2002 10:35 Sachs/Watson/IBM@IBMUS, "CPPA" <ebxml-cppa@lists.oasis-open.org> > AM Subject: RE: [ebxml-cppa] CPPA version 1.10 > > > > > > > Won't this preclude: > > <PartyId type="DUNS">123456789</PartyId> > > Since Messaging decided we MUST have a configuration file (CPA), there > doesn't > seem to be any way to use the above construct. I think MSH users MUST > import > from the CPA. > > I'm not sure whether this is good or bad but the above construct is the > method > initially envisioned by the Messaging group -- this is the example we used > during the discussions. > > David. > > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Wednesday, March 20, 2002 12:48 PM > To: Dale Moberg > Cc: Arvola Chan; Duane Nickull; Martin W Sachs; David Fischer; CPPA > Subject: Re: [ebxml-cppa] CPPA version 1.10 > > > +1 > > Dale Moberg wrote: > > >>I do not disagree that the CPA "type" values would be >>more restricted. That is kind of the point. >> >>However, MSH users do not actually have to import configuration >>parameter aggregates from CPAs. So they >>can make use of nonemptystrings >>in this PartyId/@type when not using CPAs. >> >>When they make use of CPAs, >>they will automatically follow the recommended >>policies about values for the "type" attribute >>[except for the part about >>"values be taken from the EDIRA (ISO 6523), EDIFACT >>ISO 9735 or ANSI ASC X12 I05," which I still am >>not sure how to interpret. In fact, that is part of >>our current issues that William Kammerer is going >>to fix for us, by explaining what URI will be >>used for the different naming agencies...] >> >>In other words, URIs will satisfy the MSH schema >>because they are nonEmpty strings. We will not >>have CPAs for configuration parameter aggregates >>when nonURI values are used in the type attribute. >>So the non-Recommended MSH practice of using >>strings that are not URIs is not supported by >>CPAs. >> >>Is this OK? That is what the TC needs to decide, among >>other things. Thanks Arvola for defining the issue more >>clearly. >> >> >>Dale: >> >>You said: >> >> >> >>>I had thought we had agreed to have: >>> >>><attribute name="type" type="anyURI"/> >>> >>>and make use of a separate enumeration of URIs >>>(mainly URNs) to identify the naming agencies. >>>DUNS would be one such agency. >>> >>> >>But if we specify that type should be "anyURI" and not >>"tns:non-empty-string", then we will conflict with the ebMS spec which >>states: >> >>" >>The PartyId element has a single attribute, type and the content is a >>string >>value. The type attribute indicates the domain of names to which the >>string >>in the content of the PartyId element belongs. The value of the type >>attribute MUST be mutually agreed and understood by each of the Parties. >>It >>is RECOMMENDED that the value of the type attribute be a URI. It is >>further >>recommended that these values be taken from the EDIRA (ISO 6523), >>EDIFACT >>ISO 9735 or ANSI ASC X12 I05 registries. If the PartyId type attribute >>is >>not present, the content of the PartyId element MUST be a URI [RFC2396], >>otherwise the Receiving MSH SHOULD report an error (see section 4.1.5) >>with >>errorCode set to Inconsistent and severity set to Error. It is strongly >>RECOMMENDED that the content of the PartyId element be a URI. >>" >> >>-Arvola >> >>-----Original Message----- >>From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] >>Sent: Tuesday, March 19, 2002 8:16 AM >>To: Duane Nickull; Martin W Sachs; David Fischer; Christopher Ferris; >>CPPA >>Cc: Arvola Chan (E-mail) >>Subject: RE: [ebxml-cppa] CPPA version 1.10 >> >> >>We still have unresolved discussion pertaining to >>the schema, >> >><element name="PartyId"> >> <complexType> >> <simpleContent> >> <extension base="tns:non-empty-string"> >> <attribute name="type" type="tns:non-empty-string"/> >> </extension> >> </simpleContent> >> </complexType> >></element> >> >>and to the text for this including the following >> >>" >>If the type attribute is not present, the content of >>the PartyId element MUST be a URI that conforms to [RFC2396]. >>It is RECOMMENDED that the value of the type attribute be a >>URN that defines a namespace for the value of the PartyId element. >>Typically, the URN would be registered in a well-known directory >>of organization identifiers. >> >>The following example illustrates two URI references. >> >> <tp:PartyId tp:type=" >>urn:oasis:names:tc:ebxml-cppa:partyid-type:duns">123456789</tp:PartyId> >> >> <tp:PartyId>urn:icann:example.com</tp:PartyId> >> >>The first example is the Party's DUNS number. The value is the DUNS >>number of the organization. >> >>The second example shows an arbitrary URN. This might be a URN that the >>Party has registered with IANA to identify itself directly." >> >> >> >>I had thought we had agreed to have: >> >> <attribute name="type" type="anyURI"/> >> >>and make use of a separate enumeration of URIs >>(mainly URNs) to identify the naming agencies. >>DUNS would be one such agency. >> >>William Kammerer has agreed to draft a more comprehensive >>document detailing other agencies and their >>values as a separate document. >> >>It is important that we have TC agreement >>on our plan for maintenance of PartyId/@type >>values before we go up for a vote. >> >>It is also important that we arrive at a solution satisfying: >> >>ebTWG architectural concerns >>Messaging concerns >>Registry concerns (if any exist). >> >>So I would like to get reactions to at least two ideas: >> >>1. Change the schema so that PartyId/@type takes >>anyURI values. Leave the PartyId/text() as nonEmptyString. >> >>2. Add to the text a pointer to another document >>that can be updated with a list of PartyId/@type >>URI values. >> >>Also, some reaction to: >> >>3. Should anything be said about how URIs are used >>when the type attribute is absent? Should a registered >>type URN be usable as the base URN for a PartyId URI? >> >>For example, >>urn:oasis:names:tc:ebxml-cppa:partyid-type:duns:123456789 >> >>Should we say how that this is how it MUST >>work? >> >>This is, I think, Chris Ferris's proposal. It gives >>more definiteness to the values, which should >>help out with Duane's concerns. And William K's >>separately maintained document can identify the >>base URNs, as well as examples of the convention for URI >>(and any warnings needed about escaping ':' as needed... ) >>Any URIs used without a type, are assumed to be >>particular PartyIds. >> >>Please discuss on list, and I will also put it on the somewhat >>crowded Friday morning agenda. >> >> >> >> >> >> >> >> >> > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC