Hi Paul,
I don't wish to premature with discussing formats, but my only comments
about XML is based on implementation experiences under similar design needs
for:
1) consideration of a common, "more universal" storage, fast streaming,
gating, name lookup, etc.
2) consideration to help client interfacing.
It is taken for granted that the internet (mail system) grew mostly because
of the common RFC 822 format (and complementing 821 protocol) everyone was
using.
Before then, there were many different formats which fell under two
categories: commercial/corporate (X.400, MHS, etc) and the fast growing
public early "user hosting market AKA BBS world where there were at least 22
different mail formats.
What benefits XML is that it is indeed fast becoming a new format for
interfacing. So it is worth while for consideration but there are SOME major
design issues that need to be addressed before it can be used for a NG-MAIL
type of system.
This is based on experience when consideration for a new "common XML-like
formats" (pre-XML days of course) for products that needed to interface with
many different implementations was required. Back in 94/95 or so I
presented a paper at ONE BBS CON (now called ONE ISP CON) discussing the
need for the "new data format" (which I called XNET.3) for the electronic
mail distribution and user hosting markets and also had a consideration for
what I called "Cocomp" - Cooperative Competition. The idea was based on
the need to satisfy two emerging and converging worlds of standards and
proprietary commercial implementations (mail driven events, etc).
Although, XNET.3 predated the eventually take over of the RFC 822 format,
the format design goals were:
o Easy of use, simple and powerful
o Token-based Formats
o Multi-media, mail, sound and images
o Networks, FidoNet, RIME, Internet, NewsGroup, others
o Cooperative Competition (CoComp)
o Independent Vendor Extensions
I can elaborate more, if interested.
I will summarize it by saying XML has its Pros for client interfacing but
has Cons when data processing requirements are considered for the different
NG-MAIL implementation possibilities.
NG-MAIL made end up having a "modified" more optimized mixed, binary
XML-like format.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Paul Robinson" <paul(_at_)iconoplex(_dot_)co(_dot_)uk>
To: "Martin Duerst" <duerst(_at_)w3(_dot_)org>
Cc: "Paul Smith" <paullocal(_at_)pscs(_dot_)co(_dot_)uk>;
<mail-ng(_at_)imc(_dot_)org>
Sent: Monday, February 02, 2004 7:08 PM
Subject: Re: a few short notes
....
That's it. It's BECAUSE of the incredibly strict rules you have to
follow that it is easy to write tools that handle XML.
If you can't write something like the above in say 12-20 lines, plus
standard #include'ed files in C (stdio.h), perhaps you'd like to
consider hiring me as a consultant? :-)
Now, if you then want to check your XML against an externally held XSD
or DTD, then yes, you're right it's going to be more than a dozen lines.
More like 50-100 or so.
--
Paul Robinson