[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] CPPA version 1.10
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