Re: v0.8 Manifest proposal

[Matthew MacKenzie <matt@xmlglobal.com>]

Christopher,

I can see the utility of your first example, but the usefulness of your
second (the one with the xpath) elludes me.  I would personally prefer to
keep the syntax really simple in the manifest, something like:

<Manifest>
 <DocumentReference>
  <Role
	label="purchaseOrder" 
	uri="http://www.ebxml.org/gci/purchaseOrder"/>
  <Schema
	version="1.0"
	uri="http://www.ebxml.org/gci/OrderV0.1072400.dtd"/>
 </DocumentReference>
</Manifest>

Using xlink seems like overkill, and uneccessarily munges the syntax.

Cheers,

Matt MacKenzie



On Thu, 16 Nov 2000, Christopher Ferris wrote:

> 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
>