RE: [ebxml-cppa] CPPA version 1.10

[Dale Moberg <dmoberg@cyclonecommerce.com>]

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.