Lists Home |
Date Index |
Dennis Sosnoski wrote:
> I have a hard time communicating with the hard-core text backers who
> appear to see any transformation of XML (other than gzip, which
> apparently is blessed by virtue of predating XML itself) as inherently
It's neither about text or evil. it's about the cost of being
interoperable. Text, especially highly specific text such as XML, is
cheaper in my experience to hook systems together. YMMV on this, but
mine rarely has.
As for gzip, I think there are two arguments in its favour; HTTP
support and ubiquity. if there was a binfoset with the deployed base
of gzip, that would be interesting.
> It's all just bits on the wire (or voltage levels, or photons, or
> ...), after all, and if a transform that's based on XML structure can
> deliver good performance results it seems worth a look.
If performance is what you need (in that place). And saying its all
just bits on the wire is a crashingly trivial observation, much
like saying programming langauges x, y and z are all just Turing
complete, or we are all mostly water.
> My personal
> preference is for transforms that preserve the XML Infoset,
I'd hope so :)
> Schema-based transformations such as the one used by Sun can probably
> get about twice the overall performance of Infoset-preserving transforms
> such as my own XBIS (http://xbis.sourceforge.net) for SOAP-type
> applications (assuming relatively heavy use of numeric values). Both
> types are probably worth considering.
If you can't roundtrip, then imho there's little value in not
roundtripping faster - all you're doing is reducing the mean time to
> Either way, if a tool is available that converts the transformed
> document back into XML that's equivalent (modulo canonicalization) to
> the original document, does the fact that the transformed representation
> uses funny bit fields or binary values really matter?
Yes it does, because you have to keep the codecs in sync at both
ends to roundtrip unless they are specified down to the last i and
t. I suggestion that's not yet a tenable approach for Infosets (we'd
need to harden up the Infoset first, before we bitwised any instance
of it). I believe this is where Liam is coming from in that there
should be only one.
Bill de hÓra