RE: [ebxml-iic] minutes, and next call

Jacques,

One more thing that I think makes combining <SetPayload> into the <MessageDeclaration> is that, because an XSLT processor can only output one stream ( and can only use one stylesheet at a time I believe).. multiple Payloads cannot be mutated (each with their own <Mutator> stylesheet) and attached to the outgoing message. So combining multiple <SetPayload> operations ( or even one) inside of a <MessageDeclaration> will not work, and I would think any workaround would be inefficient. Comments from implementers?

Mike

-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Tuesday, June 08, 2004 5:42 PM
To: Jacques Durand; ebXML IIC - main list (E-mail) (E-mail)
Subject: RE: [ebxml-iic] minutes, and next call - follow up comments

Jacques and all,

Here’s my comments from yesterdays’ minutes.

Mike

3. TestFramework 1.1 Follow-up on latest discussions:

- Comments on Use Case #1: why still SetPayload() used? Cant we manipulate payload directly

via the XML representation of the entire message, as we did for GetPayload()? Mike: yes

[MIKE] – I say “yes” with reservations: The current XML (using <SetPayload> ) separates message envelope

construction from payload construction and inclusion. It really requires no more XML code, and allows any type

of payload (GIF image, executable code, XML file, EDI file) to be attached, agnostic of the messaging protocol being

used. (if we eliminate the “content-ID” and “content-Location” attributes, and simply substitute “id”.

[MIKE] - Combining <SetPayload> into the <MessageDeclaration> makes sense, however it puts a burden on an XSLT processor, that cannot process non-xml content, cannot generate multiple output streams ( i.e. multiple payloads ), and cannot interface with the messaging API. XSLT is a text processor only. Trying to make it perform attachment construction (I believe) is beyond the scope of what was intended when Drake Certivo suggested using XSLT as a mutator to message envelope and payloads.

[MIKE] – It “can” be done, but that means a “2 pass” parse of the <MessageDeclaration>. Once to construct the message envelope (via XSLT), and a second pass to interpret the transport and messaging envelope declaration, as well as to interpret the <SetPayload> instruction, find the appropriate attachment ( via URI ), and bind the attachment to the message ( apriori, knowing the transport and messaging binding ) This is defined in the <ConfigurationGroup> with the <Transport> and <Envelope> configuration parameters.

Comments?

In any event, here is what a “merged” <MessageDeclaration> might look like:

<mime:MessageContainer>

<soap:Envelope>

<soap:Header>

<eb:MessageHeader>

</soap:Header>

<soap:Body>

<eb:Manifest>

</soap:Body>

</soap:Envelope>

</mime:MessageContainer>

<SetPayload id=”PORequest” > (attachment of an “inlined” XML document)

…

</PurchaseOrderRequest>

<SetPayload id=”BusinessAck” fileURI=”BusinessAck.xml”> (attachmen of an external file)

</SetPayload>

</MessageDeclaration>

Advantage: knowledge on the message envelope (MIME here) does not have to be hard coded in a

Test Driver operation.

[MIKE] – That is true. Placing <SetPayload> inside of the <MessageDeclaration> instead of external to it has no influence on whether the Test Driver is agnostic to MIME or not. Removing the mime:Content-ID and mime:Content-Location attributes, combined with providing a <ConfigurationGroup> element of

with

<Envelope>ebXML2.0</Envelope>

…. should provide the Test Driver with the knowledge it needs to construct a payload and attach it accordingly, given a generic XML declaration such as

Instead, we only have to define how the canonical XML representation of

any message, binds to a particular envelope (MIME or other) and also transport.

[MIKE] – We’ve done that with MIME and SOAP declarations for ebMS testing, although that requires the Test Driver to

1) parse the XML <MessageDeclaration> and construct the MIME parts, then

2) again parse the <MessageDeclaration> with an XSLT processor to mutate the <MessageDeclaration> and generate the proper SOAP envelope and ebXML content.

That means, if anyone wants to create an FTP test suite, the must define a canonical XML representation of the FTP envelope and transport declaration, and submit it as a schema to the IIC, so that a standard XML test suite can be generated for that particular protocol. Any IIC compliant Test Driver MUST be able to interpret that and mutate and generate the appropriate message envelope and payloads based upon that schema.

- that will keep us independent from a particular attachment representation (SwA, or other).

[MIKE] – As long as we define the underlying bindings between our XML representation and the particular messaging protocol, and provide <ConfigurationGroup> parameters that list those protocols as enumerated types .. yes..

- Pete: that amounts to defining extensibility points. We can handle future envelope formats

by just adding bindings / env types. Instead of having to redefine the semantics of SetPayload plus

having to define the binding anyway (as replacement of GetPayload).

- Monica: current small changes in BPSS will not mandate changes in use cases. WSDL support may

need be considered in new use cases. Multi-party collab will also define "segments", which in turn

define some context visibility. Can we still define these scopes of visibility?

- Monica will review current use Cases, and check if (1) they cover enough of BPSS reqs, (2) check

if there is any need for "loops" (e.g. retries, and while-do- )

- removal of Test Step concept: as long as threads can compose as well, is OK.

- Assertion op is loosing its context (FilterResult). But we can assign FilterResults to parameters,

so we can then reference them in Assertions. Several of them may need be referenced anyway, not just

the latest produced.

[MIKE] – This is true.

-----Original Message-----
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Monday, June 07, 2004 9:03 PM
To: ebXML IIC - main list (E-mail) (E-mail)
Subject: [ebxml-iic] minutes, and next call

1. Minutes attached, confirming the approval of Mike as secretary: congratulations!

2. Next call:
Time: Monday June 14, 2004, 2pm PT
Host: Fujitsu
Toll only : 1-512-225-3050
Participant code: 716071

Agenda will follow, mostly a follow-up on previous one.

Regards,

jacques
<<IIC_June_07_04_minutes.txt>>

ebxml-iic message