RE: LISP for Complex URC Sytax [WAS: Re URC func spec ]

hallam@alws.cern.ch
Thu, 24 Mar 1994 20:58:58 +0100

Date: Thu, 24 Mar 1994 20:58:58 +0100
Message-Id: <9403241958.AA26232@dxmint.cern.ch>
From: hallam@alws.cern.ch
Subject: RE: LISP for Complex URC Sytax [WAS: Re URC func spec ]

Mitra:
>So far, the players are:
> SGML parsers
> RFC822 header parsers
> UR*-of-the-day parsers

Tim:

>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,

Any whatever compromises we make in our system to comply with their
architecture they will still winge on.

I think we should aim rather on minimizing the complexity of the parser. Having
a different syntax is not necessarily that much of a problem. Anyone writing a
HTTP system in any case begins by writing an FSR compiler at the least.

If we want a simple system we use LISP. If we want a standard we should use
ASN.1

Whatever we do we should not touch SGML with a bargepole. There is a practical
benefit for using it as *A* (nb the indefinite article) format for text. Its
a format we can expect most text processors to support.

Tim agin:
>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

I think we should do this anyway. I have been ripped of to the tune of 50quid
for the SGML manual. I find it marginaly less readble than the MVS debugger
manual. Despite all the buzzwords that the SGML crowd like to throw arround
such as `validation' working out even the syntax of SGML requires a lot
of work. The typography is a disaster (this would be a nit pick except that
the subject matter is typography). If the SGML crowd want to claim any
`validation' ability I would first want to see at least a rigorous semantics
for SGML. The correspondance between a DTD and the abstract data structure
it encapsulates should be made plain as should the resulting correspondance
defined beween the text of the document and its expression in the abstract data
structure.

I can't use SGML at present within a formal system. It is by no means clear to
me that this is possible. Experience shows that a language designed informally
is unlikely to be tractable as a formal system. This was the experience of the
ADA team who ten years on have yet to produce a definitive semantics.

If we do use SGML we should do what was done with HTML. Use a very tightly
defined subset. Exclude any function that is not strictly required. By doing
so you have a system that can be proven to work.

Phill Hallam-Baker