«

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

Default User wrote:
> 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.


--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

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.

Joe Kesselman wrote:

> Default User wrote:
> > 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.

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

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

Joe Kesselman wrote:

> 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
--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

Default User wrote:
> 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.)

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

Joseph Kesselman wrote:

> Default User wrote:
> > but these are topics we are scheduled to investigate.
>
> 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

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

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!

Joseph Kesselman wrote:

> 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

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)