OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: "Binary XML" proposals



It is two uses and that is a good point 
to remember with regards to the form, fit 
and function.  Then the question would be, 
should one create an XML compression a 
la WML (language specific) or a meta-compression 
for XML given that as was stated many times 
in the past, zipping, modem compression 
etc are all there available as functions 
for that form?  IOW, how good is the fit?


Interesting RFC.  they also find they 
have to cope with mixed models by altering 
the structure (the text tag).

"March 2001"   The aliens haven't been 
here long enough to figure out if they 
truly are alien or just from New Jersey.  

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]


Len Bullard wrote,
> 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. 

Granted, but archival isn't the primary purpose of a protocol
payload. Archival _might_ be desirable for a protocol payload,
in which case I agree, Text is Good (it allows you to tail -f a 
nameserver query log, for example). We've got two different roles 
here, and it doesn't seem unreasonable for that to entail two 
different views.

Supporting an XML text based archival view of protocol messages 
would be a lot easier if protocol designers could help themselves 
to a useable binary XML encoding.

> 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?

  ftp://ftp.rfc-editor.org/in-notes/rfc3072.txt