RE: Applying transformations to Payloads (compression)

[Martin W Sachs <mwsachs@us.ibm.com>]

As was pointed out earlier, the way to say that a given collaboration is
hosting compression is in the CPA.

I agree that "compressing payloads isn't an operating business applications
thing".  Architecturally, compression should be considered an application
service.  It is outside the current scope of the TRP specification.  It is
a function which is common across many or all applications and therefore
should be implemented by the business to business middleware and invoked by
the application when needed.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Welsh, David" <David.Welsh@nordstrom.com> on 01/03/2001 02:06:35 PM

To:   "'rawlins@metronet.com'" <rawlins@metronet.com>,
      ebxml-tp@lists.ebxml.org
cc:
Subject:  RE: Applying transformations to Payloads (compression)



Mike,
My suggestion is compressed payloads is generally motivated by practical
(perceived by the press or the general public about the data size
ineffeciency of XML) efficiency concerns and compressed payloads is
something that I am today in a real business world will typically "choose
to
do" on a mutual business partner relationship & document level basis.

For example, for the same document (ex. an invoice) I may need to support
compressed payloads with some external partners, while for the same
business
document & same business operating process (same business operating rules
of
when/what/where .. I expect/handle ebXML documents relative to a prescribed
business operating set of activities) I may not be able to let compressed
payloads take place for a whole variety of business and maybe legal reasons
in some country's around the world.

There initially needs to be a way to identify that a mutually defined
collaboration between business "partners" is hosting compression,  like
there are intentions to say mutual partners are going to hhtp/s, or ...
Further, to ensure common consistancy, compressing payloads isn't an
operating business applications thing, like an inventory management
application doesn't go down to the http level ....

Thanks again
Dave Welsh


> -----Original Message-----
> From: Mike Rawlins [mailto:rawlins@metronet.com]
> Sent: Wednesday, January 03, 2001 10:37 AM
> To: ebxml-tp@lists.ebxml.org
> Subject: Re: Applying transformations to Payloads (compression)
>
>
> BTW - I just got a reject from doing a "reply/all" which
> included the TRP list.
> Can we keep this discussion to just one list and not do cross-posting?
>
> Mike Rawlins wrote:
>
> > If I may go back a few steps to my original comment about
> the business need,
> > Mr. Welsh came forward as one user with a specific need for
> compression.  At
> > least one other person offered a perceived need for SME's
> in Europe sending
> > XML over VANs to have compression.   We have seen several
> proposed technical
> > solutions, but not a concise statement of the requirement.
>  May I suggest we
> > can focus more clearly on the best solution by first more
> clearly defining the
> > requirement?  For starters, I'll take a stab at it:
> >
> > ebXML must provide the ability to indicate that part or all
> of a message
> > payload is compressed, and if compressed, the compression method.
> >
> > Note I don't say *how* we provide the ability (MHS or CPP),
> but just that we
> > do.
> >
> > Issue:
> >
> > All documents or selective:  Will it suffice to say that
> *all* documents and
> > payloads between two entities will be compressed, or is
> there a need to
> > specify compression on a per document basis?
> >
> > Cheers,
> > --
> > Michael C. Rawlins, Rawlins EC Consulting
> > http://www.metronet.com/~rawlins/
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> http://www.metronet.com/~rawlins/
>
>