> IFF may be nicely machine-readable, but machine-processing suffers
> because non-length-preserving edits to a block require backpatching
> of the length fields in all the containing blocks, and multiple
> random-access writes play havoc with locality and concurrency.
>
> Note that convenient-to-read and convenient-to-write are usually
> at odds.
Hmmm, markup languages are being used to annotate web content, which
is where we came in, so I'm going to backtrack in the conversation a
bit.
For situations like serving out much static web content at present,
machine processing is less of an issue, as you're effectively writing
once and reading the same thing back for delivery many times; reading
therefore takes precedence.
Being convenient to write is not an issue here; prerendering as much
content with as much processing as possible (compression, block
markup, etc) for the benefit of the transfer and reading processes
makes sense, and IFF could arguably make a better inline
all-in-one-stream container than some experiments I've seen with
multipart MIME. (Netscape 1.0, prior to the introduction of animated
GIFs, springs to mind here, and HTML MIME email is quite simply a
legacy adaption that deserves abortion.)
Read/write symmetry for ease of editing and processing of information
into a clear form that rises as far up the curve of entropy as
possible are goals that will always conflict; e.g Microsoft Word is a
(proprietary, undocumented) editing format that exhibits massive
redundancy for necessary write symmetry (at least, I hope
that's why it exhibits massive redundancy), but you're not going to
use it to mass-deliver documents to people electronically if you've
got any sense, because it's messy and bloated for the very same
reason. So you render to the (slightly better) pdf.
> http://www.amazon.com/exec/obidos/ISBN=1558601902/forkrecommendedrA
Transaction Processing : Concepts and Techniques
(Morgan Kaufmann Series in Data Management Systems)
by Jim Gray, Andreas Reuter
Is the web at present really a transaction system? No - much of it is
just static recordings that are played back on request, and simple
requests barely qualify as transactions. The trifling irony of the URL
entrypoint to the proprietary transaction-processing database system
I'm quoting above apart, much of the web resembles a jukebox, and IFF
could build a better jukebox for you, trading unused flexibility (all
that content negotiation that never really happened, for example) for
improvement of limited delivery modes that require clearly-flagged
types of wholly prerendered content.
I thin the real irony here is that you're recommending a _book_ on
transaction processing. The amount of work that goes into editing and
rendering a book for mass delivery and reading shows clear lack of
symmetry. It shows us that the delivery of much worthwhile information
doesn't _need_ editing symmetry, because that information is usually
prerendered and static, and the resulting flow of information and
content is generally one way.
Optimising for reading and delivery makes sense; IFF has that much
right.
L.
<L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641