Re: v0.8 Manifest proposal

[Matthew MacKenzie <matt@xmlglobal.com>]

Christopher, Group:

Having entered the trp discussion rather late, and not having
familiarized myself with all of the specs, I have no really strong
feeling toward including the xlink syntax, especially if it helps
with SOAP interoperability.  If its addition buys the specification a
longer lifetime, so be it.

One thing that I am wondering about the manifest, now that this discussion 
has brought it, is the question of applying a sequence to the processing
of attachment items.  I was thinking of something like matching the ID in
the document reference to the Content-ID in the attachments MIME headers,
and specifying sequence by adding am attribute (sequence="") to the
DocumentReference element.  There may be instances where successful
processing of one attachment hinges on another attachment is processed
first.

Comments?

-Matt








On Thu, 16 Nov 2000, Christopher Ferris wrote:

> Matt,
> 
> You may be thinking auto-actuate, but I am not.
> However, I am thinking ahead;-) I've dropped
> a few hints in that regard. 
> 
> You will note that I haven't expressly included 
> xlink:show and xlink:actuate attributes, yet, other 
> than to allow that they MAY be included (#IMPLIED).
> 
> In fact, for processing the ebXML Header, I envision
> that the DocumentReference be treated with the behavior
> semantics of show=none and actuate=onLoad. Quite
> possibly, what is needed for this proposal is to
> make that explicit in the specification following
> the lead taken in the xlink spec w/r/t behavior treatment
> of arcs in a linkbase:
> 	'Applications encountering arc-type elements in 
> 	linkbase lists must treat the behavior attributes 
> 	as if they were specified as show="none" and 
> 	actuate="onLoad", even if other values were 
> 	specified.'
> 
> As to the processing of the header (not parsing),
> here is what I had envisaged:
> 	- ebXMLHeader document is parsed with the
> 	behavior cited above
> 	- the MSH can now extract information from
> 	the header which can be used by it (and/or the
> 	"application support" software layer) to
> 	route/process the message internally
> 	- being able to zoom into the CPA at the point
> 	where the message (and its constraints) is 
> 	defined within the service can be useful to
> 	an application support layer which wants to
> 	do pre-application-process checking/enforcement
> 	as it can now easily extract (from the CPA)
> 	the constraints, etc. This is what I had in mind for
> 	the xpointer/xpath use case proposal
> 
> As to your point regarding 'spending too much time
> figuring out what to do...' it is my belief that
> some amount of processing must be peformed to
> determine where/how the message should be processed.
> I think that this is unavoidable unless you have
> a MSH which is an endpoint for a single message type
> (e.g. a servlet)
> 
> Of course, this is only a proposal, and this sort of 
> discussion is what it was intended to solicit;-)
> Regardless, I am interested in tightening up the
> Manifest as I believe that it is too vague in its
> present specification. I am also interested in 
> ensuring that we find a means of including an
> externalization of the schema/dtd reference and
> a version qualifier for same based upon requests
> made to me.
> 
> Cheers,
> 
> Chris
> 	
> 
> 
> Matthew MacKenzie wrote:
> > 
> > Christopher,
> > 
> > I am not the least bit concerned with human readability, I am more concerned
> > with how practical certain constructs may be for a machine.  When I think
> > xlink, I think auto-actuate.  If it is acceptable for an ebxml header parser
> > to make an arbitrary number of callouts to include data, then xlink and the
> > functionality it brings is perfect, but if we want to minimize the
> > processing that happens on a header, the xpath approach may be a problem.
> > My concern is that more time will be spent figuring out what to do with a
> > request than fulfilling it is too much stuff creeps into the header.
> > 
> > Cheers,
> > 
> > Matt
> > 
> > On Thu, 16 Nov 2000, Christopher Ferris - XTC Advanced Development wrote:
> > 
> > > Matt,
> > >
> > > Thanks for the comments. As to unnecessarily munging
> > > the syntax, I'm not certain that I agree. It isn't
> > > clear to me that we need to be concerned with "human"
> > > readable syntax if that's what you are after.
> > >
> > > Again, my rationale for proposing xlink syntax
> > > is that it is more closely aligned with the direction
> > > expressed by the SOAP with Attachments specification
> > > and thus offers us a better opportunity down the road for
> > > convergence with the likes of XP.
> > >
> > > I can see the merits of changing the subordinate element
> > > name of Metadata to Schema since that's currently all that
> > > is being cited w/r/t metadata.
> > >
> > > 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:...">
> > >               <Schema version="1.0"
> > >                          href="http://www.ebxml.org/gci/OrderV0.1072400.dtd"/>
> > >       </DocumentReference>
> > > </Manifest>
> > >
> > > As to my second use case using xpath (or xpointer) the
> > > usefulness is that you can explicitly identify a node
> > > in the CPA (Collaboration Protocol Agreement, which is
> > > derivative of TPA from tpaML) which corresponds to the
> > > "step/sequence" within a business process for which the
> > > message is intended.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > >
> > >
> > > Matthew MacKenzie wrote:
> > > >
> > > > 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
> > > > >
> > >
> > >
> > 
> > --
> > Matthew MacKenzie
> > XMLGlobal Technologies
> 
> -- 
>                                Christopher Ferris
>     _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced Development 
>    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063      
>   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
>        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
> _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903
>