MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fwd: [ebxml-cppa] Packaging extension: Transform
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]