Fwd: [ebxml-cppa] Packaging extension: Transform

[Martin Sachs <msachs@cyclonecommerce.com>]

The following message was directed to the CPPA team but may also be related 
to the MSG team.

Regards,
Marty

>X-XWall-Bayes: 19
>From: "jim.wowchuk@marketboomer.com" <jim.wowchuk@marketboomer.com>
>To: "ebxml-cppa@lists.oasis-open.org" <ebxml-cppa@lists.oasis-open.org>
>Subject: [ebxml-cppa] Packaging extension: Transform
>Date: Wed, 12 Nov 2003 00:04:26 -0700
>X-Assembled-By: XWall v3.28
>X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
>X-OriginalArrivalTime: 12 Nov 2003 00:36:40.0415 (UTC) 
>FILETIME=[09D72EF0:01C3A8B5]
>
>
>One of my concerns with the current ebXML standards is that as written it
>doesn't meet our real-world need.  While it would be great if everyone used
>HTTP or even SMTP, we have customers that use FTP or even Kermit on dial-up
>modems.  And we would be happy if everyone would send XML based payload
>documents, we have many that send fixed-record length, comma separated
>variables (csv), excel spreadsheets or PDF files.  If the packaging is
>ebXML, well and good, but if they want to use SOAP 1.2 with WSDL, XML-RPC
>or simply push a document as the entire body of an email or http POST, then
>we need to cater for it.  But we want only one Message Service Handler
>(MSH).
>
>For the most part, our CPPA copes with it and I commend the developers of
>these protocols and vocabularies that allow us to work so well.  In almost
>all cases, we try to keep the payload opaque.  If the packaging doesn't
>provide the 'per message' control variables, then we use the ones found in
>the CPA.  If we can't identify the CPA then we imply it on the CPP of the
>remote party.   The CPPA helps us establish the business processing and
>document exchange rules for these documents, the reliability and the
>security.
>
>One of the things we learned doing XSL-FO, was that where we may have one
>application process producing or processing a document, we may need to
>present it in a number of ways.  Our Request Purchase Order process may be
>sent as a fax (graphic), a pdf, attached as an XML document based on our
>schema definition or perhaps our customers' to an email, or in some file
>format natively compatible with their back-end system.  To this end we have
>extended the Packaging element to support Transform elements.  We may use
>XSLT for transforming the payloads, or POJOs or simple scripts running
>through a script engine, or dedicated programs with piped input & output.
>We are also able to do this on both 'public' side of our MSH and our
>private Application Service Interface (ASI).
>
>In this way we are able to make the MSH implement ebXML features without
>necessarily using ebXML packaging (as it stands).
>
>Of course, such transforms, being out-of-scope of the standard, prevents us
>from automated publishing and negotiation.  So what is needed to have this
>considered for incorporation in the standard?
>
>Jim Wowchuk               jim.wowchuk@marketboomer.com
>Chief Technology Officer  marketboomer Pty Ltd
>  _--_|\                   Post:  36-42 Waterloo Road
>/      \                         Macquarie Park, NSW 2113
>\_.--._/ <---Sydney NSW   Phone: +61 (2) 8870 3370 #3357 Mobile: 0419 262
>706
>        v      Australia   Fax:   +61 (2) 8870 3399
>
>
>
>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-cppa/members/leave_workgroup.php. 
>

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com