[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: v0.8 Manifest proposal
David, See below for my 2¢ worth. Henry -------------------- At 12:46 PM 11/17/2000 -0800, 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. >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 For "what they each mean" do you mean semantics which is not in an XML or some other document? For example, I'm thinking of the "test" flag which RosettaNet apparently has and was discussed on the Thursday ConCall. If you do, should we provide an application header where semantics such as this can be specified and accompany the documents on their travels? I'm not experienced in business applications, but if we are going to be transporting pre-defined documents that business analysts can't alter for some reason, they might find something like this useful -- of course, they can always put it into their own document and bung it in the payload. > b) what if any documents are to be obtained from a remote location >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?). >4. We can't hope to second guess what XP will do on manifests at this early >stage of XP's development I agree that we shouldn't worry about XP, but, judging by the way the XP WG process is set up, I'd bet it turns out to look a whole lot like SOAP. > >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 >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 >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. IMHO, TRP has a better envelope, too -- not to say that security and reliable messaging aren't important. Unless they come up with something good (the list xml-dist-app has been trying without too much success), XP is going to have problems with binary data. Henry > >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 >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC