Re: [ebxml-iic] Proposed extension to include document processing in IIC framework

["Michael Kass" <michael.kass@nist.gov>]

Tim and Serm,

   I think that your suggestions for modification of the Test Framework to
support mutation
of message payloads is great.

   I agree with Serm, in that an XSLT solution may be a better choice than
XUpate,
if for no other reason that XSLT is more established as a specification,
with many more choices for open and
freely available implementations.  We viewed XUpdate as yet another method
for accomplishing the task.

   I am not sure wither URI resolving of filenames vs. setting an attribute
is a better choice.  I guess it gets down
to what "other" choices we envision for mutating a payload ( if there are
any ).  In addition, some people may want
to directly "inline" their XML, or may use an EDI payload...

   But in any case, I think that this is a great way to modify payloads.  I
am wondering if we should also address
message envelope in a similar manner, particularly with the issue of the
Test Framework being heavily
"ebXML oriented"  in regard to message enveloping right now.

   It should be possible to extend the "ebTest" schema to support XSLT
mutation of both message payload and message
envelope, without affecting backward compatibilty with version 1.0 of the
specification.

  Comments?

Mike




----- Original Message ----- 
From: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov>
To: <ebxml-iic@lists.oasis-open.org>
Sent: Tuesday, September 16, 2003 11:22 AM
Subject: Re: [ebxml-iic] Proposed extension to include document processing
in IIC framework


> ----- Original Message ----- 
> From: "Tim Sakach" <tsakach@certivo.net>
> To: <ebxml-iic@lists.oasis-open.org>
> Sent: Monday, September 15, 2003 4:16 PM
> Subject: [ebxml-iic] Proposed extension to include document processing in
> IIC framework
>
>
> The proposal is to extend the <FileURI> semantics in
> <PutMessage><SetPayload>. If the file's extension is a stylesheet, then
the
> test driver will obtain the stylesheet from the URI and transform a
message
> in the MessageStore and then set the payload of the current PutMessage to
> the resulting xml.
>
> <PutMessage>
>     <SetPayload>
>         <FileURI>Purchase2Confirmation.xsl</FileURI>
>     </SetPayload>
> </PutMessage>
>
>
> <<<<<serm>>>>>Tim, are the proposal above and below alternatives with the
> same desired functionality? If so, I prefer the top one. However, it looks
> like the bottom approach provides more targeted mutation. My question
about
> the top approach is how the test driver know which payload to apply the
XSL
> file. Also, I think instead of relying on the file extension to determine
> the mutation, should we consider instead using an attribute to the FileURI
> to tell the test driver exactly what to do with the message.
> <<<<<<</serm>>>>>>>>
>
>
>
> Doing this would allow the test driver to create a response message that
> contains run time data, not static default data from base files. This
would
> also eliminate the extensive use of <SetParameter> that would be needed to
> simulate the same behavior. Using static base xml files is still an option
> since the proposed change is an extension.
>
> Using stylesheets would also allow the test driver to create mutated and
> malformed response messages based on the incoming message. However, a
> <ModifyPayload> instruction with XUpdate support can also be added to the
> framework to accomplish the task of modifying a payload after it is has
been
> imported.
>
> <PutMessage>
>     <SetPayload>
>         <FileURI>ConfirmationBase.xml</FileURI>
>     </SetPayload>
>     <ModifyPayload>
>         <XUpdate>xupdatemutationfile.xml</XUpdate>
>         <UseParameter>
>             <Name>MyParam</Name>
>             <Value>Xpath to change or static value</Value>
>         </UseParameter>
>     </ModiyPayload>
> </PutMessage>
>
>
> The XUpdate or UseParameter operation would be performed after the
> SetPayload instruction.
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the
> OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgroup.php.
>
>
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgroup.php.
>
>
>
>