new CPP/CPA DTD element/attribute descriptions

[christopher ferris <chris.ferris@east.sun.com>]

All,

Below you will find some descriptions of selected elements and
attributes which are either new (in relation to tpaML1.0.6) or
or that may be unfamiliar with regards to their intended use.

I'll send out a revised DTD and examples (that those with windows
can open;-) later today...

I used the Xpath language in the descriptions below. 
e.g. Element/@attribute 

to identify and place context around the item being discussed. 
The spec does not need to use this form... I just find it
convenient;-)

As I go through the DTD in detail, certain things are popping
out as missing (oops! mea culpa;-) which I have documented here:

- no means of referencing a Party's detailed information from CPP or CPA
(e.g. an UDDI entry, LDAP DN, or other URL)
	- proposal: add PartyDetails element that can include an URI
	to the Party's contact, address, etc. information.
	e.g. <!ELEMENT PartyDetails EMPTY>
	     <!ATTLIST PartyDetails 
			xlink:type 'locator' #FIXED 'locator'
			xlink:href CDATA #REQUIRED>
	we can discuss the element's cardinality (0..1, 0..unbounded, 1..1)

- Dale's packaging reference(s)

Cheers,

Chris

- Party/@partyId an XML ID that MAY be used to locate or cross-reference
a given party either from within the document via an IDREF or an
Xpath/Xpointer
reference, or externally as an Xpath/Xpointer reference.

e.g.
xpath/xpointer syntax - //Party[@partyId = 'N01']/Role[@name = 'seller']
would find the 'seller' Role element of the Party with a partyId value
of 'N01'.

- Party/Role/ServiceBinding 
- DeliveryChannel/ServiceBinding - the ServiceBinding element is new and
provides a means of identifying/associating multiple "service
interfaces"
with a given Role. This has the value of enabling a search or match
based on
Role performed and a particular service.

- PartyId - the PartyId element has a cardinality of 1..unbounded. This
permits there to be multiple instances of an identifer, one of which
SHALL be used
within either a To or From element in the TR&P header document.
	- note, in the CPA, do we need a means of identifying WHICH of the
	various PartyId elements will be used for each party? Do we excise
	those which are NOT to be used? This remains unanswered.
The PartyId element is the same as is used in TR&P.

- Protocol/@version - this element is used in a number of places within
the
CPP and CPA. In tpaML, the Protocol element stood on its own and had a
parallel Version element which was used to qualify the Protocol. I have 
basically merged Protocol and Version into a single element Protocol
that has a version attribute to qualify/identify a specific version
of a given protocol.

- Transport/Endpoint - The Endpoint element provides a container
to hold the URI by which the Transport is engaged. For HTTP it would
be an HTTP URL. e.g. http://example.com/servlet/ebxmlhandler
for SMTP, it would be a mailto URL. e.g. mailto:chris.feris@sun.com.
FTP, IIOP and other protocols usually have a URI scheme, so this
works well. I have also provided (off line I think) examples of
how an MQSeries URI might be structured. I'll leave that to IBM
to formalize should they so desire.

Endpoint has two attributes; type and uri. The type attribute 
distinguishes the Endpoint as being login, error or request (maybe
normal or traffic might be more suitable?)

The uri attribute holds the actual URI. An alternate form for this
element
might be to type the element as an URI, but we'd need XMLSchema to 
do this effectively. It isn't clear that we want to go down this 
path just yet. We could, as TR&P have done so already, so we would
not be breaking new ground...

- Certificate/ds:KeyInfo - This has been discussed on the list. I chose
the XMLDSIG KeyInfo element to hold the details of the certificate
as this seems to be a flexible and well thought out (as well as near
Recommendation of the W3C) means of holding the information needed to
convey a certificate's information either by reference (RetrievalMethod)
or by value and with the option of including PKI info as well.

- CertificateRef - This element holds an IDREF to a Certificate element
so that it may be referenced elsewhere in the document. It is used in
a number of places in both the CPP and CPA.

- ReliableMessaging - This element holds the requisite information
to convey the Reliable Messaging information needed by the TR&P MS
to effect reliable message delivery semantics.

- CollaborationProtocol - This element is an xlink locator which points
to an externally defined business process (such as one registered
with RegRep).

- ebXMLBinding - This element contains all of the ebXML binding
information that describes a DocExchange whcih uses ebXML. The
DocExchange
MAY be extended in the future to add in XP, SOAP, RNIF and possibly
other messaging protocols. We need only focus on ebXML for now;-)

- ebXMLBinding/NamespaceSupported - This multiply occuring element
identifies the namespace extensions supported by the implementation.
Examples might include S2ML, XAML, etc. 

- Status - This was discussed at the face2face meeting. It provides
a means of characterizing a CPA as being inforce or in the process of
being negotiated (where two parties might pass a proposed CPA between
them as they negotiate the specifics of the agreement. I tinkered
with the idea of adding a 'signed' value to the enumeration to 
indicate that the CPA has been digitally signed by the parties.
However, the mere presence of a ds:Signature element should make that
same point;-)

- bpm:BinaryCollaboration - placeholder for BPM stuff

- bpm:ProcessSpecification - placeholder for BPM stuff

- bpm:BusinessTransactionActivity - placeholder for BPM stuff

- ds:Signature - an XMLDSIG defined signature element which occurs
multiply
allowing each party to sign the CPP or CPA. No claims are made as to 
how it is created. That will be left to XMLDSIG spec and the
capabilities
of the parties to the CPA;-)
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard