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