OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: John's thoughts on purity, goals, transport

<quote from="John Ibbotson">
> OK, having a full in-basket this morning leads me to offer some
> observations:
> 1.   I think we're entering a religious debate on XML purity for the
> transport. I believe that the the performance implications of adopting a
> pure approach is potentially
>      unworkable. The purist approach says that there should be a single
> root document per message with all the sub-parts of the message in XML.
> explosion in data   once binary data is UUENCODEd together with the need
> parse the ENTIRE message (SAX or DOM) means that any server implementing
> this is going to perform      like a dog !!

Do you have any hard data here, or is this mainly an experienced intuition?
How large are you expecting typical UUencoded binary data to become?  Are
you expecting CPU time, memory usage, or network bandwidth to be the
limiting factor?  The last can certainly be solved by compression.  The
first two are certainly more sticky.

<<John I>> No hard data here but experienced intuition !! Efficient
compression usually requires significant redundancy in the data being
compressed. Straight XML is fine since it contains a lot of whitespace and
there are tricks you can do in replacing element tags with symbols -
similar to LZW compression in images. However, when presented with
UUENCODEd binary data you are presented with long strings of characters
which cannot be sufficiently compressed - at least not enough to compensate
for the data explosion from raw binary in the first case. I just believe
that the data will explode in size and the implications in parsing such
large messages will make such a proposal a joke.

> Coming up with a complete
> schema that (potentially) allows multiple business objects or multiple
> enveloped messages inside a single envelope is I        believe too
> for this group to achieve in a respectable timescale.

That is a different matter altogether.  With outside analysts already
expecting us to lag behind our schedule, the KISS principle (Keep It Short
and Simple) definitely applies to these sorts of decisions.  I am not
suggesting that do shoddy work, but rather that we chart courses around
mountains rather than through or over them.

<<John I>>Agree completely !!

> We have to come up
> with a proposal that allows us to envelope different data components
> which over the medium to long term will migrate to XML - though I believe
> binary won't go away for a long time even with the expectations of XML
> compression.

That sounds like an entirely reasonable position.

> 2.   What are we standardising on ? This section may appear to be rather
> political compromise argument !! Is our role to define the message
> structure or the services (API     or otherwise) that the messages
> If the second (services), then the message structure is hidden behind the
> service definitions. The service definitions can then   support "pure
> The enveloping/structure of the message is then hidden behind the service
> interface definition and gives us some flexibility in implementation. OK,
>      realise that the units of interchange are the messages themselves so
> we do need to expose the structure - I did say this was a political
> argument :-)

I would call it more of a philosophical than a political argument.  What
we trying to accomplish?  Are we modeling structures or processes?  I agree
that modeling processes necessarily includes modeling structures, but the
reverse is not true.  It is a matter of scope and perspective.  I am
wholeheartedly in favor of modeling processes.

<<John I>>Unfortunately interoperability gets in the way of this one. It is
the message that gets exchange and therefore there has to be a common
representation for its structure. However, I still think we could define
the message as non-XML pure and pas pure XML out at the service interface.

> 3.   We must support different transports. Email is going to be around
> a long time as well as fax and telephone. Businesses are going to use
> and we risk alienating
>      communities if we adopt an inverse-Luddite approach and ignore them.
> Fine, I guess I'll have another full in-basket tomorrow !!

I find it wryly ironic that so much e-mail is being exchanged on the
of whether e-mail is obsolete.  Next I expect a conference call on the
subject of archaic phone technology.

<<John I>> Amen !!

-- Roger Glover
   Norstan Consulting
   * E-mail: Roger.Glover@NorstanConsulting.com
   * Office: +1-612-352-5718
   * FAX:    +1-612-238-5718

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC