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] 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