RE: "Binary XML" proposals

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

It usually comes back to cost recovery in the 
lifecycle .  

SGML CALS proponents argued for 
years for the advantages of markup in the 
long lifecycle systems and were proven 
right.  

In a short lifecycle message format (system 
outlasts or is more pervasive than data) where you 
can either throw it away or archive it, 
one gets back to form, fit and function 
debates.  SGML wasn't used for protocols, 
so maybe this is a new wrinkle, but I suggest 
it is more related to archival so in that 
sense, the same advantages:  recoverability 
and reusability.  Addressing INTO a binary 
requires some tricks not used a lot since 
HyTime unless one is mapping to an abstraction.

Ever since the SGML binary discussions (circa 93?), 
this idea comes up at least biannually.  It is like 
aliens: if they are here, where are they?  The 
binary requirements can be asserted but one soon 
discovers that versions exist, none have been 
adopted widely and begins to ask why.  The 
answer is usually that all other tradeoffs 
and conditions accounted for, there isn't 
enough cost benefit to justify adding yet 
another format to the support soup.  Do protocol 
requirements offer a more compelling case 
than short lifecycle documents (where WYSIWYG 
turned out to be a good idea over markup: 
final fixed format vs archival format)?

That said, press on.  It's like a soap 
opera where one waits to see if the 
new character is good or evil:  great 
entertainment but the plot remains the same.

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Miles Sabin [mailto:MSabin@interx.com]

True in the document world, perhaps. But not so obviously true
in the protocol world. For example, DNS question and answer 
payloads are an example of an open, structured, binary format.
There are many others.