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


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