W3C home > Mailing lists > Public > public-soap-jms@w3.org > November 2010

Re: Allow EXI as characterization for XML in the JMS body ?

From: Amelia A Lewis <alewis@tibco.com>
Date: Tue, 9 Nov 2010 10:05:00 -0500
To: Jean-Baptiste Bugeaud <bugeaud@gmail.com>
Cc: public-soap-jms@w3.org
Message-ID: <20101109100500705855.02e2c517@tibco.com>
What specific changes would need to be made to the specification in 
order to avoid ruling out the use of EXI?

I'm phrasing this differently than you have, of course: I do not think 
incorporating an EXI *requirement* is in scope for the SOAP/JMS working 
group.  In fact, I do not think, at this stage of the specification 
work, that we ought to introduce a new optional dependency.  However, I 
will readily acknowledge that a vendor might wish to enable EXI in SOAP 
over JMS, and if our specification forbids it, we shouldn't.

Rephrasing: I think we should not forbid, nor require, nor even specify 
as optional behavior the use of EXI in SOAP over JMS, but should phrase 
our specification in such a way that a person or group writing an 
extension specification could make using EXI possible and interoperable.

On Mon, 8 Nov 2010 19:40:58 +0100, Jean-Baptiste Bugeaud wrote:
> Dear SOAP-JMS Editors,
> Could it be possible to allow EXI characterisation (see
> http://www.w3.org/TR/exi/) in the message body 2.4 as well ?
> Using EXI makes sense in a JMS context for any mission critical system
> where latency has to be kept at a the minimum.
> EXI would also help a lot :
>  - keeping XML processing CPU overhead low (message inspection for
> active routing for instance)
>  - handling & streaming of huge attachement (base64bin saved as octet
> binary set for instance)
>  - etc
> Regards,
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
Received on Tuesday, 9 November 2010 15:05:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:22 UTC