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


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