[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: "Binary XML" proposals
> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|