RE: [ebxml-cppa] CPPA version 1.10

[Dale Moberg <dmoberg@cyclonecommerce.com>]

From: David Fischer [mailto:david@drummondgroup.com]
Sent: Thursday, March 21, 2002 8:36 AM
To: Christopher Ferris; Dale Moberg
Cc: Arvola Chan; Duane Nickull; Martin W Sachs; CPPA
Subject: RE: [ebxml-cppa] CPPA version 1.10

DF writes>
"Won't this preclude:

	<PartyId type="DUNS">123456789</PartyId>"

No, it does not preclude MSH from agreeing to use "DUNS"
as their type identifier. To do that, however,
MSH will need to obtain configuration parameter aggregate
("CPA") information from the user or from some 
other non-ebXML format for profile information. 

Already MSH recommends using a URI for type values.
We are trying to adjust to BPSS and ebTWG and Registry
pressures to use URIs (more specically, URNs) in these
roles. So we are faced with a choice about how/who to
align, and cannot do it both ways.

IMO, the closest alignment is to mandate URIs and
thus be in alignment with what MSH recommends
and what the other groups indicate as required.

The TC has not formed a consensus on this, however.

So, we may begin to standardize the
treatment of naming agencies and allow extensions
to be made in a uniform way, even when naming
agencies do not use URIs themselves as their
PartyId datatype.  Using URNs allows
us to possibly tap into a URN resolution service
provided by registries (or a simple web service)
that will document naming agency value semantics.
We don't have to rewrite the schema or the spec
to add these new agencies, so the hope is that
maintenance hassles will be reduced.

Dale

DF continues>

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.

DM> Not the way I understood your spec.

DF> 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.

DM> I think you should have used an example that conformed to what
you recommend as a practice...

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