Re: Applying transformations to Payloads

[Mike Rawlins <rawlins@metronet.com>]

I think I would want to hear directly from someone who has a business need for compression before we
went to any trouble to support it.  My view on this is that if someone is really concerned about data
volumes and compression, they won't be using XML anyway - they'll probably be using traditional EDI with
compression on top of it.

"Welsh, David" wrote:

> Thanks for the attention. I certainly don't want to "throw a curve at this
> late stage" tot he group.
> Is 'transforms' and 'encoding' the same thing ?
>
> Given there's several orders of magnitude of increased data (text) volume
> size usually (well in my experience) involved (see attached example from the
> BP group of a business process document, and you could say it's not that
> much bigger but multiply the extra overhead by 10's of thousands of orders
> and ...), and I also suspect given most people (especially the SME's won't
> have the luxury of T1, DSL or high speed access to an ISP), I was hoping
> there'd be a way to allow for compressed / non-compressed payloads to be
> indicated.
>
> Not everyone probably could support a compressed payload, and to support
> compression probably could be something extra in a normal exhange; but if
> trading partners could go the extra step and support compression then it
> seems reasonable that there'd be some realistic chance of company's being
> more efficient; time to process, time to transmit, cost of services, .. !
>
> Thanks again
> Dave Welsh
>
> > -----Original Message-----
> > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Tuesday, January 02, 2001 5:43 AM
> > To: Burdett, David
> > Cc: ebxml-tp@lists.ebxml.org; 'Welsh, David'
> > Subject: Re: Applying transformations to Payloads
> >
> >
> > David,
> >
> > Not transforms per se, but there is an encoding element
> > that theoretically could be used.
> >
> > It might be more flexible to simply allow for some
> > set of transforms to be defined as they have done for
> > XMLDSIG which can be extended to arbitrary xslt transforms
> > specified by the user/programmer.
> >
> > Of course, this will need to be discussed after Marty has a draft
> > published, hopefully, sometime very soon!
> >
> > Cheers,
> >
> > Chris
> >
> > "Burdett, David" wrote:
> > >
> > > I've been exchanging emails with David Welsh at Nordstrom
> > about the idea of
> > > compressing data inside the payload of an ebXML message.
> > However before you
> > > could do this, it would be useful if information on the
> > ability to accept
> > > this (or any other) type of transformation in the payload
> > was recorded in
> > > the CPP/CPA.
> > >
> > > Is there a facility to support this in the CPP/CPA
> > >
> > > Regards
> > >
> > > David
> > >
> > > Product Management, Commerce One
> > > 4400 Rosewood Drive, Pleasanton, CA 94588, USA
> > > Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> > > mailto:david.burdett@commerceone.com; Web:
> > http://www.commerceone.com
> >
>
>   ------------------------------------------------------------------------
>
> Subject: DTD & Sample - Specification Schema for review
> Date: Mon, 1 Jan 2001 11:44:25 -0700
> From: Cory Casanave <cory-c@dataaccess.com>
> Reply-To: Karsten Riemer <Karsten.Riemer@East.Sun.COM>
> To: 'Karsten Riemer ' <Karsten.Riemer@East.Sun.COM>,
>      "'ebxml-bp@lists.ebxml.org '" <ebxml-bp@lists.ebxml.org>,
>      "'ebxml-core@lists.ebxml.org '" <ebxml-core@lists.ebxml.org>
>
>  <<ebXmlSpecifcationSample090.xml>>  <<ebXmlSpecificationDTD090.dtd>>
>  Enclosed is the DTD which matches the ebXml Specification Schema 0.90 and a
> sample of it's use.  Note that we do not have an
> Automated generator or parser for this yet so it is done by hand and could
> have errors.  It is valid XML.
>
> The following comments are derived from the process of making the sample and
> schema;
>
> 1. Important! We must define a set of "core" types.  To make the example, I
> assumed the following:
>                       Integer, String (Simple), Text (IE HTML), Float,
> Decimal, Date, Time,
>                       DateTime, Currency, Duration.
>                       Other built-in types may be added by core components
>
> 2. There is no apparent difference between "document" (representing
> "Structured Document") and "aggregate", other than one can be in a document
> set and one can not - so why have the distinction? (The same is true for
> document-set, but some people seem to Really want this).
>
> 3. Having to define document sets all the time is annoying.  Perhaps
> reference to a document type in a business transaction can imply a document
> set.
>
> 4. It is not clear if the user can make new "Basic Information Entities" or
> if this is just for built-in types.  It is not currently in the DTD.
>
> 5. There is no way, as there is in XML, to define reusable attribute types.
>
> 6. There are some times I would have wanted to put the delivery attributes o
> the data type as well as the attribute.
>
> 7. Document set should inherit from information entity so it can be used in
> attributes, as is done in the example.
>
> 8. I assume we want to be able to document models, I added this to the DTD
> but it is not in the model.
>
> -----Original Message-----
> From: Karsten Riemer
> To: ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
> Sent: 12/30/00 7:09 PM
> Subject: Specification Schema for review
>
> Hi,
> attached is the BP Specification Schema.
> It will be discussed in this coming Tuesday's metamodel meeting and if
> no
> major issues are raised it will be submitted to QR on Wednesday 1/3. It
> will
> be accompanied by a DTD and a set of patterns. Paul, please send call
> info for
> Tuesday's meeting to BP and Core lists.
>
> thanks,
> -karsten
>  <<WinZip>>
>
>   ------------------------------------------------------------------------
>                                      Name: ebXmlSpecifcationSample090.xml
>    ebXmlSpecifcationSample090.xml    Type: XML Document (text/xml)
>                                  Encoding: QUOTED-PRINTABLE
>
>                                    Name: ebXmlSpecificationDTD090.dtd
>    ebXmlSpecificationDTD090.dtd    Type: DTD File (application/x-unknown-content-type-dtd_auto_file)
>                                Encoding: QUOTED-PRINTABLE

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/