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

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.

Amy!
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,
> JB BUGEAUD
> 
> 
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com