Lists Home |
Date Index |
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.
i guess if you're going down this path you'd like to see an analysis of
it's performance vis a vis the xml<->asn.1 tools.
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.
Wolfgang Hoschek wrote:
> On Feb 9, 2005, at 11:49 AM, Bob Foster wrote:
>> Bullard, Claude L (Len) wrote:
>>> Hmm. Format camps. Now there's a thought.
>> Please Daddy don't send me to format camp! It's no fun there. They
>> just argue all the time and nobody plays together.
> Yep, no fun there. And most of the argueing either way is more
> handwaving FUD than arguments backed up by facts.
> I'd be glad if one could articulate what's conceptually wrong about
> the intended usage and performance numbers of a practical binary xml
> example, say, the bnux binary xml codec
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
tel;cell:+61 411 287 530