Re: v0.8 Manifest proposal

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

Matt,

This hasn't been raised as yet. It may be something we should
consider. I would expect that one of the payload entries is the
primary and that the others are either referenced by it or
that the consuming software "knows" what to do with multiple
payloads.

Of course, our thinking may not have gotten that far down
this path.

Can you provide a real-world use case which we could
use to work through this?

Thanks,

Chris

Matthew MacKenzie wrote:
> 
> 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
> >
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:;;One Network Drive;Burlington;Ma;01803-0903;USA
version:2.1
email;internet:chris.ferris@east.sun.com
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard