Re: v0.8 Manifest proposal

[Matthew MacKenzie <matt@xmlglobal.com>]

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