[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-iic] minutes, and next call - follow up comments
|
Jacques, my comments below: Mike -----Original
Message----- >[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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]