[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
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: <MessageDeclaration> <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
xmlns=”xxx”> … </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 <Transport>HTTP1.1</Transport>
or <Transport>SMTP</Transport>
or <Transport>FTP</Transport>
with <Envelope>SOAP1.2</Envelope>
or <Envelope>ebXML2.0</Envelope>
or <Envelope>none</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 <SetPayload
id=”abc” fileURI=”def”/> 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----- 1. Minutes attached,
confirming the approval of Mike as secretary: congratulations! 2. Next call: Agenda will follow,
mostly a follow-up on previous one. Regards, jacques |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]