Lists Home |
Date Index |
Michael Champion wrote:
> So IMHO, interop is quite possible *if* there are a small
> number of widely supported serialization standards
> and XML text is mandated as the fallback in content
> negotiation protocols.
Yes. It is important to point out that for any new
protocols, XML should be considered to be the default
encoding. The only exceptions, and there are always
exceptions, would be applications like sending telemetry from
Mars where every bit counts... (But, even in such cases, it
would still be useful to have the XML support if only to
assist in debugging during development...)
> Others (such as myself) are open to maybe 2-3 more for
> specialized environments where, for example, bandwidth must
> be optimized while processing minimized (wireless), parsing
> performance is critical but bandwidth is cheap (web
> services infrastructure), and maybe one more (perhaps
> ASN.1) for situations where you want to exchange
> objects/PSVI/XQuery data models and you can assume that
> both sides agree on the schema.
Can you say more about why it might make sense to define
new, non-ASN.1 binary encodings as you seem to refer to above?
ASN.1 PER is good at producing compact encodings and can be
parsed very rapidly. Thus, it would seem to satisfy the needs
you specify -- except that it does require that the schema be
known by both sides. I'm not sure how you would get the
tightest encoding and fastest parsing without relying on
schema knowledge. Knowledge of the schema allows you to do
things like remove field names from the bitstream and also
allows you to optimize the parsing structures.
I know that there have been a variety of suggestions for
doing things like removing the need for endtags in XML by
inserting field-length counts, using *zip functions to do
compression, or sending data with built in dictionaries of
strings used more than once... Is this the kind of thing
you're talking about? Can you name some of that non-ASN.1
candidates that you think should be seriously considered?
>>Joshua Allen wrote:
>>... some of the problems with these binary formats is that
>> they tended to evolve, and the new information embedded
>> in the binary stream is not always added in a way
>> that is most amenable to efficient parsing. ...
>Ahh, that has the ring of truth! Thanks.
The ASN.1 defined encodings have been in use for a very
long time and are, I believe, unlikely to change any time
soon... I believe you can consider them to be stable.