[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xml-bin] RE: Another binary XML approach
- From: Al Snell <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 13 Apr 2001 00:51:18 +0100 (BST)
On Thu, 12 Apr 2001, Derek Denny-Brown wrote:
> >avoid reinventing the wheel
> Reinventing the Wheel, is always an issue, but there is a time and a
> place. Why XML at all since you could just use SGML? To steal from Tim
> Bray's recent hit/miss presentation; one good reason to reinvent is to
> adjust an existing standard to better 'hit' the 80% that matters.
Why XML instead of ASN.1 or XDR (in the http://RFC.net/rfc1832.html
sense)? All XML really *adds* is that the structure and some comments
(element + attribute names) goes in the file. An ASN.1 encoding that does
that could be easily defined, or the ASN.1 records prefixed with a header
containing some kind of identifier (perhaps a URL to the ASN.1 description
file!) that would allow the debugging tools that came with the ASN.1
toolkit the developer was using to view and hand-edit the records. But XML
as a data format came into the limelight instead, and all this schema
stuff is reinventing the work done on ASN.1 or XDR files... it's all just
part of this industry that people keep reinventing the wheel.
Self describing data formats very similar to XML existed around 1960, I
think - LISP is based on one:
name: "Alaric Snell"
addresses: ((email . "email@example.com")
(phone . "0845 090 8101")))
...look familiar? :-)
Very little these days is new. Things succeed because vendors hype them,
which happens when the sales department stumbles across the potential of
something - not when that "revolutionary cutting edge technology" was
developed two decades ago :-)
> be using XML(-ish). If the format is extensible, so that it is possible
> to stick application specific blocks of data inline, then it will be
> much easier for groups to move from a purely proprietary solution to a
> XML-centric solution.
<applause level="much">Hear hear!</applause>
> One worry I do have about a standard, is that the format will bloat. If
> a standardization group does form, it should be a hard limit that a
> parser for this new format could conform to the 10:2 ratio I mention
> above, or something close to it. Feature creep is something which must
> be fought tooth and nail, or else there is no purpose to creating the
> new format.
Yeah. My approach to this is to form a small hard core and throw together
a spec right now, without a standards body - like independent RFCs - then
get it Out There so the standards body ends up taking it on.
> -- Technical Lead: MSXML --
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software