Date: Thu, 24 Mar 94 13:19:54 +0100
From: Tim Berners-Lee <timbl@ptpc00.cern.ch>
Message-Id: <9403241219.AA14575@ptpc00.cern.ch>
To: Simon E Spero <ses@tipper.oit.unc.edu>
Subject: Re: LISP for Complex URC Sytax [WAS: Re URC func spec ]
> Date: Wed, 23 Mar 94 20:32:16 -0500
> From: Simon E Spero <ses@tipper.oit.unc.edu>
>
> Using a lisp syntax is a great idea (hell, my next home system is going to
be
> a symbolics 3645); however it might be more appropriate to use SGML to
> do structured text. If you compare the number of HTML pages out there with
> the number of completed IAFA templates, it's clear that using RFC822 style
> layout isn't always a big win.
I agree completely with Mitra and Dan that the structure ought to
be evident. This rules out simple RFC822 headers.
(I say this even though HTTP uses them for URC info
at the moment.)
I propose that the definition of the field names and values in
the structure be done as a separte effort from the decision
on a standard encoding/presentation. It looks at first
glance that, as the structures only contain as field values
strings and otehr structures, it will be simple to define mappings
onto LISP, and SGML syntaxes.
I agree with Simon that SGML would be the proper way to go in this
case (horrid though it is in detail). We would have the same problem which
we had with HTML (except worse) that the SGML crowd will want every
URC to start <!DOCTYPE URC SYSTEM> and will want a full entity-processing
engine behind any parser, but we can do the same thing as Dan
did for HTML, ie describe the relationship between the two carefully
as to how you can make a URC into a valid SGML document
for parsing, and emphasis that just because a URC can be wrapped
up to form an SGML document conforming to a given DTD
(whatever that realy is ;-) that doesn't mean that any SGML document
conforming to the DTD will be a valid URC. SGML people will complain,
but they are on shakey ground as if they were to insist, then LISP
would just become infinitely preferable.
Maybe Dave Crocker and Dan Connolly should get together and
rigourously define a "cleaned up" version of SGML, with the
phase-of-the-moon white space handling Dan refers to in a
recent message weeded out, etc, with a 1 page BNF descrition
and 150 page optionally legible description of how to map
between SGML and cleaned up SGML.
The mapping into ASN/1 and BER will of course be possible too.
Tim