OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Pushing all the buttons

[ Lists Home | Date Index | Thread 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 
> evil. 

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 :)

> but 
> 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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS