Jacques,
my comments below:
Mike
-----Original
Message-----
From: Jacques
Durand [mailto:JDurand@us.fujitsu.com]
Sent: Sunday, June 13, 2004 5:26
PM
To: 'Michael Kass';
Jacques Durand; ebXML IIC - main list (E-mail) (E-mail)
Cc: tsakach@certivo.net
Subject: RE: [ebxml-iic] minutes, and
next call - follow up comments
>[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).
[MIKE3]
- This is true. It depends which
API someone uses when they write their Test Driver. But by agreeing that we needed a
"generic" way to allow someone to specify "any" type of
message
envelope (using XSLT to interpret a <MessageDeclaration> and create the
appropriate envelope), we have a flexible system that permits any
type of message envelope (SOAP, RNIF...etc.. ) and
separates
creation of that envelope from the addition of a message payload. If our goal is to be able to satisfy
every type of API, then we would need some kind of generic
<MessageDeclaration> that can be
used
for
all types of message protocols, all envelopes and all types of messages. We already include "hints" to the Test
Driver through the <ConfigurationGroup> <Transport> and
<Envelope> parameters.
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.
[MIKE3]
- It sounds like you are saying that an implementor must support both API and
XSLT, since I may write my <PutMessage> operation using the
<Mutator> to transform it into a viable message while another test
writer may define their <PutMessage> operation without a
<Mutator>, relying on an underlying API to interpret the declaratoin and
generate the message. That would
work if we state in the specification that, in the absence of a
<Mutator> element a <MessageDeclaration> MUST be interpreted by an
appropriate API. (That was how the Test Framework was originally
specified). But again, that places an additional
burden on Test Driver developers to support both methods, and support any
number of APIS for other types of
messaging.
The
<Mutator> proposal was originally submitted by Drake Certivo as a way to
support flexible message construction without the need to support multiple
messaging APIs. We at NIST are
using XSLT in our implementation
to generate SOAP/ebXML or possibly other messages using XSLT. We DO use the MIME API for
encapsulating the message and attaching payloads, so we do have that level of
API support.
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.
[MIKE]
- I'm not sure that placing everything inside a single element ( as opposed to
two elements <MessageDeclaration> and <SetPayload> ) is a significant difference. And in
fact,
they
are both inside <PutMessage> anyway, so you could think of them as
residing inside a single element
already.
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...
[MIKE]
- To support both an XSLT <Mutator> and a messagin
API(s) places a significant burden on Test Driver implementers. That's my comment. Comments from Drake
Certivo?
Jacques