[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "Binary XML" proposals
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Miles Sabin <MSabin@interx.com>,"'email@example.com'" <firstname.lastname@example.org>
- Date: Tue, 10 Apr 2001 13:13:36 -0500
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.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
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
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?