MTOM/XOP

[Default User]

I'm working on a research and development project involving binary XML.
I've been reading lots about the new MTOM and XOP recommendations put
out by W3. I'm interested in trying to find a toolset that we could
evaluate as part of this effort, so I thought I'd check and see if
anyone has used or is otherwise familiar with such packages.

What we need at this stage is:

1. Open source. We just want to do concept work at this point.

2. Linux compatible.

3. The tech guy wants a Python API (although that looks tough). I'd
prefer C or C++. I'm not a Java guy, but won't rule it out.


I'm currently looking at gSoap:
<http://sourceforge.net/projects/gsoap2>



Tungsten has gotten some buzz, but I haven't looked at it much:

<http://www.wso2.com/products/tungsten/>



Another possibility:

<http://docs.codehaus.org/display/XFIRE/Home>



If anyone has feedback about these, or suggestions for other avenues,
I'd appreciate hearing from you.




Brian

 

[Joe Kesselman]

I'm working on a research and development project involving binary XML.

Binary XML (misnomer!) is not a recommendation yet; it's exploratory
work. Past experiments have generally suggested that:

1) The advantages of "binary XML" are less than a naive view claims.
Zip-style data compression is better at saving bytes, and a good parser
is surprisingly efficient -- even more so if it leverages some of the
work IBM has done on using schema information to create optimized
parsers. (A schema-validating parser can actually be _faster_ than a
non-validating parser!)

2) No two parties agree on exactly which competing needs "binary XML"
needs to be optimized for.

3) Anyone who really worries about performance winds up using XML as a
portability/interchange representation, and switching to a more
specialized data representation within their tools, with code and data
tailored to each other. That's true even if you're doing general XML
infoset storage and manipulation; you decide in advance which needs are
most important and optimize for them.

There is still an effort in progress to see if some common compromise is
possible... but frankly I expect it to fail. XML's textual
representation -- the fact that it is accessible to the "desperate perl
hacker" with minimal investment in education, and that a moderately
clueful student can implement a moderately efficient system moderately
quickly -- really does turn out to be a key strength.

Don't take my word for it. Maybe someone out there really does have a
new insight that will make this concept worthwhile. But personally, I
recommend that you take a step back, ask what problems you're really
trying to solve, and think hard about whether binary XML -- especially
in its current unstable forms -- is seriously helpful or just a buzzword
and distraction.

 

[Joe Kesselman]

Hm. I stand corrected about status.

XOP has in fact been reported out as a Recommendation. It appears to be
primarily intended as an attempt to avoid re-encoding of binary data
already available in a base-64 representation, rather than a compressed
representation of ordinary XML itself. MTOM builds on XOP within the
context of SOAP.

I recognize some of the names on both specs as more-than-usually clueful
individuals.

None the less, I still stand by my assessment of the general topic of
binary XML representations. As a special-purpose tool, fine. As more
than that... it still appears to mean giving up too much of what XML is
in exchange for an incomplete optimization. Bad tradeoff, in my view.
Your milage may vary.

 

[Default User]

Binary XML (misnomer!) is not a recommendation yet; it's exploratory
work. Past experiments have generally suggested that:

1) The advantages of "binary XML" are less than a naive view claims.
Zip-style data compression is better at saving bytes, and a good
parser is surprisingly efficient -- even more so if it leverages some
of the work IBM has done on using schema information to create
optimized parsers. (A schema-validating parser can actually be faster
than a non-validating parser!)

2) No two parties agree on exactly which competing needs "binary XML"
needs to be optimized for.

3) Anyone who really worries about performance winds up using XML as
a portability/interchange representation, and switching to a more
specialized data representation within their tools, with code and
data tailored to each other. That's true even if you're doing general
XML infoset storage and manipulation; you decide in advance which
needs are most important and optimize for them.

These are good points, and that's part of what R&D in the aerospace
business is about. You try see where the state of the art is, and try
some prototypes applying that to common use cases in our business.

There is still an effort in progress to see if some common compromise
is possible... but frankly I expect it to fail. XML's textual
representation -- the fact that it is accessible to the "desperate
perl hacker" with minimal investment in education, and that a
moderately clueful student can implement a moderately efficient
system moderately quickly -- really does turn out to be a key
strength.

That's not really of concern.

Don't take my word for it. Maybe someone out there really does have a
new insight that will make this concept worthwhile. But personally, I
recommend that you take a step back, ask what problems you're really
trying to solve, and think hard about whether binary XML --
especially in its current unstable forms -- is seriously helpful or
just a buzzword and distraction.

Well, this is the job for 2-1/2 engineers through the end of this year,
and likely beyond.



Brian

 

[Default User]

Hm. I stand corrected about status.

XOP has in fact been reported out as a Recommendation. It appears to
be primarily intended as an attempt to avoid re-encoding of binary
data already available in a base-64 representation, rather than a
compressed representation of ordinary XML itself. MTOM builds on XOP
within the context of SOAP.

That's why I'm interested in exploring it versus DIME or SwA. It seems
like it might have more future stability. If this goes as my boss and
the tech lead envision, we'll be working on Web Services for avionics
systems for the next few years.

I'm certainly aware of and will look into the compression issue. Cokus
and Winkowski had an interesting research project on that score.

None the less, I still stand by my assessment of the general topic of
binary XML representations. As a special-purpose tool, fine. As more
than that... it still appears to mean giving up too much of what XML
is in exchange for an incomplete optimization. Bad tradeoff, in my
view. Your milage may vary.

I've read the paper by Nottingham et al, where many concerns about the
state of the art in 2003 were raised. It's a good background for the
situation now, which is very much in flux.

We are pretty specialized. We'll be looking systems for transmitting
the kind of data that the (potential) customers want, on platforms
representative of our typical usage.

I've read so many papers on the subject of binary XML and the main
implementations so far that my eyes are bleeding. I understand what
you're saying, but these are topics we are scheduled to investigate.




Brian

 

[Joseph Kesselman]

but these are topics we are scheduled to investigate.

Good 'nuff. Your application may be in a niche where this makes sense.

(I've pinged Noah to ask if there's a good paper he could recommend
which summarizes the current best-practice/best-guess.)

 

[Default User]

Good 'nuff. Your application may be in a niche where this makes sense.

We hope so. It's not general web services, it's web services for
propriatary platforms (I hesitate here to say "embedded" as that has
caused confusion in the past).

(I've pinged Noah to ask if there's a good paper he could recommend
which summarizes the current best-practice/best-guess.)

I appreciate that.



Brian

 

[Joseph Kesselman]

OK, here's what I've been able to gather:

MTOM is reportedly gaining popularity specifically as a way of passing
non-XML (eg binary) data as a base-64-encoded block of data within one
of the XML elements of the SOAP message. "MTOM will allow suitably
enabled SOAP bindings to optimize the transmission of such things."

This is a very different matter from past uses of the term "binary XML",
which were talking about alternate representations of XML rather than
ways of using XML to represent binary... which is what I (erroneously?)
assumed you were interested in.

Apologies if we've been talking at cross purposes!

 

[Default User]

OK, here's what I've been able to gather:

MTOM is reportedly gaining popularity specifically as a way of
passing non-XML (eg binary) data as a base-64-encoded block of data
within one of the XML elements of the SOAP message. "MTOM will allow
suitably enabled SOAP bindings to optimize the transmission of such
things."

This is a very different matter from past uses of the term "binary
XML", which were talking about alternate representations of XML
rather than ways of using XML to represent binary... which is what I
(erroneously?) assumed you were interested in.

Apologies if we've been talking at cross purposes!

It does seem to be a somewhat vague at times. We are looking into
attaching binary data (the actual data is still TBD) and route to
various users on the network.




Brian