[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: v0.8 Manifest proposal
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC