[
Lists Home |
Date Index |
Thread Index
]
On Feb 9, 2005, at 1:17 PM, Rick Marshall wrote:
> even it's own documentation says this is not a binary xml format (at
> least that we can rely on) because the authors reserve the right to
> change it at will and warn against storing a bnux transformed document
> because it may not be able to be decoded in the future.
>
> how many xml principles does this break? perhaps it could be question
> of the week :)
>
> worse - the encoder/decoder must therefore be deployed in pairs - and
> upgraded in pairs. this may later become the basis of something, but
> it is along way from being a binary xml coding that is useful in
> general.
That's because binary XML makes most sense in tightly coupled systems
(and the intended usage is clearly stated as such - there's no
ambiguity here).
>
> and finally if gzip/zip type compressions can add even more - why not
> just use them and put the effort into more efficient gzip algorithms -
> or better still a gzip encoder/decoder chip :) for use in mobile
> phones etc.
Better compression does not necessarily equal better performance. GZIP
is very compute-intensive, it actually degrades performance (while it
does offer more compression). You can verify this yourself via the
compressionLevel flag. There's an explicit tradeoff here to be made.
|
