v0.8 Manifest proposal

[Christopher Ferris <chris.ferris@east.sun.com>]

All,

I've been doing quite a bit of thinking about our v0.8
Manifest. I would like to submit a proposal for
changing the current (0.8) Manifest element
with the objective of making it more precise
in its semantic meaning.

Specifically, I've been considering the use of 
XLink (http://www.w3.org/TR/xlink) for purposes of 
representing the DocumentReference. My proposal is that the
DocumentReference becomes an XLink simple link which
is roughly equivalent to an <A href=""> in HTML.

From the XLink spec:

	Simple links offer shorthand syntax for a common kind 
	of link, an outbound link with exactly two participating
        resources (into which category HTML-style A and IMG links 
	fall). Because simple links offer less functionality than
        extended links, they have no special internal structure.

My objective in proposing the use of XLink in this context is 
NOT to impose complexity or even require use of an XLink processor 
on an ebXML message. Rather, to provide for a more precise definition 
of the Manifest element semantics, by leveraging the XLink namespace and
its element and attribute semantics.

e.g.
	<Manifest xmlns:xlink="http://www.w3.org/1999/xlink">
		<DocumentReference xlink:type="simple"
			xlink:role="http://www.ebxml.org/gci/purchaseOrder"
			xlink:href="cid:...">
			<MetaData version="1.0" 
				schemaLocation="http://www.ebxml.org/gci/OrderV0.1072400.dtd"/>
		</DocumentReference>		
	</Manifest>

Specifically, I propose that the current DocumentLabel element be eliminated
and that its puropose be transferred to an xlink:role attribute of the DocumentReference
element. DocumentLabel is really pretty loose in the current version of the
spec. I would suggest that we make it expressly clear that it is RECOMMENDED
that the value of an xlink:role be a URI reference to one of:
	- request message type within a specific business process registered
	in an ebXML registry/repository
	- an xpath or XPointer expression into the CPA which governs the message,
	identified by the CPAID element
I would actually prefer the latter as it might make things easier to implement
and it is certainly quite explicit as to which step in a choreography the
message is intended to represent.

e.g.
	xlink:role="//ServiceInterface[InterfaceId = 'foo']/ActionMenu/Action[ActionId =
'xxx']/Request[RequestName = 'blahblah']"

you get the idea...

I also propose that DocumentId element be eliminated and its purpose be
transferred to the xlink:href attribute (new) of the DocumentReference element.
I think that it is quite clear what this should represent.

It would seem to me that any valid XLink attribute of a simple link be
permitted (e.g. OPTIONAL in cardinality) to be used. Specifically, 
xlink:title and the xlink:show and xlink:actuaute attributes. I'm not so
clear on whether we should include xlink:arcrole. That would possibly be
something for discussion.

I also propose that we add a new element Metadata which would have
the following definition:

	<!ELEMENT Metadata EMPTY>
	<!ATTLIST Metadata version CDATA #IMPLIED
			schemaLocation CDATA #IMPLIED>

The version attribute would be used to permit the version of the
document's schema/dtd to be reflected externally to the referenced
document. This has actually been something which has been recognised
as extreemly valuable to a number of vertical working groups (e.g.
OTA). I have received off-list requests that a version identifier
be added to our Manifest on more than one occasion.

The schemaLocation attribute I added to allow for the DTD or schema
to be externally accessible to the software agent processing the
message. This too has been communicated as an important feature.

I would suggest that we make the Metadata element OPTIONAL in cardinality
and OPTIONAL to implement on either the producer or consumer of a
message. Basically, the Metadata element is purely informative content
which is most likely avilable elsewhere in the message.

Of pros and cons, I would submit the following:
	- this approach offers an easier migration to XP (assuming
	that SOAP 1.1 with Attachments manages to find its way
	into XP).
	- this approach is more explicit in its semantic meaning
	and interpretation due to leveraging the semantic meaning
	of the xlink specification (currently CR status)

So, our DTD would be revised with something along the
lines of the following:

	<!ELEMENT Manifest (DocumentReference*)>
	<!ATTLIST Manifest xmlns:xlink CDATA #FIXED 'http://www.w3.org/1999/xlink'>

	<!ELEMENT DocumentReference (Metadata?)>
	<!ATTLIST DocumentReference  xlink:type    CDATA  #FIXED 'simple'
        	xlink:role    CDATA  #REQUIRED
        	xlink:href    CDATA  #REQUIRED
        	xlink:show    CDATA  #IMPLIED
                xlink:actuate CDATA  #IMPLIED
               	xlink:title   CDATA  #IMPLIED >

	<!ELEMENT Metadata EMPTY>
	<!ATTLIST Metadata  version        CDATA  #IMPLIED
                    schemaLocation CDATA  #IMPLIED >
	
Comments?

Chris