[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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