Re: "Binary XML" proposals

[David Brownell <david-b@pacbell.net>]

> OK, I misread the question. But then perhaps the real question
> wasn't a very good one. DNS is a client-server protocol, so why
> shouldn't diversity amongst the clients count?

Because when you talk about systems ecologies, the
scarce components (in this case, server implementations
that really affect the ecosystem) dominate evolution.
For client/server protocols, clients aren't scarce.

I was disproving your comment about DNS supporting
evolution as flexibly as text based protocols.  The
underlying issue isn't binary vs text ... it's the fact that
skills and tools for one are more available than the other
in most of the relevant environments.


> >     So the easier it is for
> > customers to detect and publicize such vendor bugs, the
> > better the market serves customer (not vendor) needs.
> 
> Err ... well, I don't have any evidence to back this up, but I'd
> be prepared to bet quite a lot that non-conformance ...
>    [is] detected when things fail unexpectedly.

There are several stages to finding/fixing the conformance
issues.  I'd agree that later "systems integration" stages
tend to turn up different sorts of bugs than the earlier ones.
Even in well tested systems, which are way too rare!


>     I'd hazard a guess that failures in binary protocols 
> tend to come to light at least as quickly as failures in text 
> protocols. Probably quicker, because binary protocols tend to 
> leave less slack.

We could argue about that for arbitrarily long, because there
are individual cases on so many points in the spectrum.  Slack
comes from the system's fault handling design ... "draconian"
or otherwise.

- Dave