Re: v0.8 Manifest proposal

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

David,

Please see below.

Cheers,
Chris

"Burdett, David" wrote:
> 
> Folks
> 
> Catching up on this thread ... so heres my $0.02c worth.
> 
> My take on the manifest issue is the following ...
> 1. In TRP we are defining a mechanism for transferring messages that will be
> used by business protocol/document choreography designers.

The messages will be designed by designers, not necessarily used by them.

> 2. This means that these designers will need to specify:
>   a) what goes in the payload: 1 document, 2 documents, etc and what they
> each mean
>   b) what if any documents are to be obtained from a remote location

Correct.

> 3. I don't think that there is a need to point to part of a payload, or to
> part of a resource held remotely on the web as this will be within the
> control of the business process/message designer (anyone disagree?).

Not yet;-)

> 4. We can't hope to second guess what XP will do on manifests at this early
> stage of XP's development

We can get there first;-)

> 
> So my conclusion is the following:
> 1. The role/document label can be kept a simple string provided that it is
> kept unique within Service and Action (which must also be specified by the
> business process/message designer

An xlink:role MUST be an URI. See the spec. My proposal was to have the xlink:role
URI be an xpath into the CPA which identifies the message within the
service/action to which a payload entry maps. The href the URI into the
MIME container which represents the object fulfilling that role.

> 2. We only need href as a method of pointing to either a complete part of a
> MIME part in the payload, or to a URL on the web

Agreed, but an URI is not constrained in this way. Certainly, there's
no reason that it be used otherwise.

> 3. We should aim in our version to keep this simple and let XP take its
> course on the development of the manifest structure. The value of TRP, IMO,
> is going to be more in the areas of security and reliable messaging.

Agreed on the value proposition of TR&P MS. I don't necessarily agree that
we should simply defer doing a reasonably good job in defining a useful
manifest. It isn't clear at all to me that XP has even considered a Manifest
in their charter or the requirements put forth thus far.

> 
> Just my 2c
> 
> David
> 
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Friday, November 17, 2000 5:19 AM
> To: Matthew MacKenzie
> Cc: ebXML Transport (E-mail)
> Subject: Re: v0.8 Manifest proposal
> 
> 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