XOM API for Processing XML with Java

[Steve Loughran <steve.loughran AT gmail.com>]

On 7/7/05, Elliotte Harold <elharo AT metalab.unc.edu> wrote:
> Steve Loughran wrote:
> 
> > Agreed. A better solution would be for XML parsers to be able to
> > handle arbitrary large incoming data by letting you provide a factory
> > for storing big values that could be used to stream to a cache. It
> > would be more general purpose.
> 
> Actually that sounds pretty special purpose to me. There just aren't
> that many reasonable use cases that have such large values in the first
> place. A lot of the whole XOP/MTOM/SOAP mess seems to derive from the
> principle that everything should be stored in an XML document. I don't
> hold to that principle. There are some things that just don't belong in
> XML, and large binary files like JPEGs and MPEGs are some of them. You'd
> be better off storing both the XML and the binary data in some sort of
> archive format like a zip rather than trying to treat it as one thing.
> This is is essentially what OpenOffice does, and it works pretty well
> without unnecessarily contorting the nature of XML and XML APIs.

I think the SOAP problem is not the 'everything must be XML' mindset,
so much as 'all communications must be over SOAP, there is no HTTP
other than POST and error codes 200 and 500'. Once you rely on all
communications being SOAP operations, you start having to look for
ways to send binary stuff in the message (SwA, DIME, MTOM), ways to
replace stuff that was handled by GET quite easily (WS-Metadata), and
then dedicate a whole working group (WS-I) to nail down exactly how a
SOAP stack should handle a 302 error code (badly).

Its why the pragmatism of REST has an advantage -it is
content-agnostic. Even so, I'd like to see the rest equivalent of
SOAPFaults; a well known XML document to return on an error, one that
can be easily turned into human readable content by the browser/a
standard XSLT, but yet which provides more machine readable. info than
just '500', I do not advocate SOAPFault itself in this role, for
reasons which become clear to anyone implementing the specification
(as I am currently doing for the second time in my life)