[
Lists Home |
Date Index |
Thread Index
]
On Wednesday 05 February 2003 14:28, Robin Berjon wrote:
> Rich Salz wrote:
> > How much of the problem "XML needs to be compressed" is solved by just
> > using GZIP transfer encoding over HTTP?
>
> As Alaric said, it solves the size problem, but that's just about it.
> Depending on the platform it may worsen the speed problem. Here are your
> typical requirements for a binary infosets format (they are met by very few
> of the available options):
>
> - size
> - speed (parsing time)
> - streaming (the ability to send the document in independent, yet
> well-formed as per the binary format, fragments. Those are possibly sent in
> an order that does not match that of the document. This ties in strongly
> with XML Fragments and XML Packaging)
> - random access (being able to skip straight to the portion of the document
> you want, without having to parse it all)
>
> In addition to that you might want things like backward/forward
> compatibility accross schema changes.
I'd add "debuggability" - ease of writing a generic viewer/editor. XML gets
around this by being partly editable without looking up a schema; you can
look at the document and guess what things mean and where they're allowed, or
carry a copy of the schema in your head, and there can be references in the
XML to a schema. Under ASN.1, in the original protocol model the protocol
carrying it would declare the global name of the ASN.1 module in use - a bit
like a namespace URI - which can be used to look up the schema
programmatically so your packet debugger would always be able to find the
schema, but now people bundle it over yucky IP protocols that don't do this
for you so you end up needing to tell your debugger what schema to use.
Somebody needs to get around to rejoining the two models and incorporating
ASN.1 types into the MIME type hierachy so things can work automatically
again:
Content-Type: asn1/1.2.826.0.1.4062548.1.0; encoding=PER
That would be nice.
ABS
--
A city is like a large, complex, rabbit
- ARP
|
