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

>[MIKE2] - The use of <parameter name= "" ></Parameter> is fine. The <Mutator> XSLT stylesheet would interpret that,

>and generate an appropriate ebXML <MessageHeader>

>XSLT however, is NOT capable of constructing MIME envelopes and their content. That is best left to an API, so placing:

<payload></payload> inside of a <MessageDeclaration> is problematic. It is best left "outside" of <MessageDeclaration>. Perhaps

>a way to make it clearer is to change the

>name of <MessageDeclaration> to <MessageEnvelopeDeclaration>. XML message envelope declarations are easily manipulated

>via XSLT. MIME (or other) payloads are not. We "could"

>put <payload> elements inside of <MessageDeclaration> .. but it just means that we must ignore them during XSLT processing,

>then reparse <MessageDeclaration> again so that

>we can do "API-level" manipulation of attachments, based upon the <payload> element content. Why not keep payload processing

>separate from message envelope processing?

Either way, the processing model would remain the same indeed: (1) build the XML headers (XSLT), (2) generate the envelope and attach payloads (via API calls that interpret SetPayload()).

The concern I have, in a general case, is that sometimes the API may not allow building part of the message with API, and part of it outside API (I am talking of a messaging-specific API, not MIME).

For example, attaching payloads will sometimes affect the header (e.g. add payload references to a a manifest), and the API takes care of this *provided that the header has been created with a previous API call*.

In thecase I describe, Test Driver scripting must allow to build the entire message (header and attachements) via API calls (i.e.

we may not have the liberty to craft the envelope via XSLT). So in that case the "parameters" for header would be interpreted into

API calls themeselves.

I admit taht the scripting alternative above is mostly a matter of style, though packaging all info about the message in

a single XML element makes it easier to then delegate the whole thing to a message builder package, in the case

where everything is built with API calls.

So if the Test Driver interpretation of header data allows different interpretation (API calls)

in addition to directly generating XML envelope (e.g. with a mutator),

then that is sufficient to address my concern...

Jacques

ebxml-iic message