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 ebXML
> 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.
The
> explosion in data   once binary data is UUENCODEd together with the need
to
> parse the ENTIRE message (SAX or DOM) means that any server implementing
> this is going to perform      like a dog !!
</quote>

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.

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

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.


<quote>
> 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.
</quote>

That sounds like an entirely reasonable position.


<quote>
> 2.   What are we standardising on ? This section may appear to be rather a
> political compromise argument !! Is our role to define the message
> structure or the services (API     or otherwise) that the messages
support?
> If the second (services), then the message structure is hidden behind the
> service definitions. The service definitions can then   support "pure
XML".
> The enveloping/structure of the message is then hidden behind the service
> interface definition and gives us some flexibility in implementation. OK,
I
>      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 :-)
</quote>

I would call it more of a philosophical than a political argument.  What are
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.

<quote>
> 3.   We must support different transports. Email is going to be around for
> a long time as well as fax and telephone. Businesses are going to use
these
> 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 !!
</quote>

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


-- 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