Agreed. I did say "many of the same intents," and not "precisely
the same intentions."
Most of the recent "enhancements" to HTML seem to be directed
towards allowing authors to make the "look" more "duplicious."
> > If you argued that LISP should supplant both Java and HTML,
> > that would at least have logic to it, as that family of
> > languages integrates treatment of programs and data. (Some
> > might counterargue on the grounds of "complexity" or because
> > they hate parenthesis, which aren't *fundamental* grounds.)
> >
> In one sense, though, wouldn't you have to put LISP and Java on
> one side, and HTML on the other? In that LISP and Java are
> both procedural: you can program a sequence of actions; this
> would seem to be the main perceived deficiency (which is also a
> strength!) of HTML.
Nope. I would put LISP on *both* sides of the fence.
I said precisely what I meant when I said:
"integrates treatment of programs and data."
LISP has both procedural *and* descriptive capabilities. You
can write programs in LISP (ala Java); you can create readily
parsable specifications/descriptions in LISP.
One could build an "L-HTML" ("LISP-HTML") document looking like:
(HTML
(HEAD
(TITLE "Title of document"))
(BODY
(H1 "Header 1")
(P "Here's a paragraph...")))
Which corresponds *precisely* to:
<HTML>
<HEAD>
<TITLE>Title of document</TITLE>
<BODY>
<H1> Header 1</H1>
<p>Here's a paragraph...</p>
</BODY>
</HTML>
Once the document has been turned into the form of the LISP
list, it can readily be broken up and analyzed however one
might wish.
Doing this sort of conversion isn't unusual; this is exactly
the sort of approach taken with some of of the HTML processors.
They would parse documents, turning them into big LISP lists,
and then use tools in LISP (or Scheme) to manipulate them.
The "HoTMetaL" HTML system uses this approach (e.g. - its
internal "engine" is written using Lisp (I believe the Scheme
variant) and is on sale at the average PC warehouse store...
In article <340be22f...@news.tornado.be> bart.me...@tornado.be (Bart Lateur) writes:
>1) How would you represent raw text (PCDATA) with embedded tags, e.g.
>some bold text inside a plain paragraph?
>
>The SGML for this could look like
>
> <P>This is a <B>very</B> interesting topic.</P>
(P This is a (B very) interesting topic.)
Happy happy joy joy
--
Patric Jonsson,d88...@nada.kth.se;Joy, Happiness, and Banana Mochas all round.
(P "This is a "
(B "very")
" interesting topic.")
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
[Trimmed to comp.lang.lisp,comp.text.sgml]
Christopher Browne <cbbr...@hex.net> wrote:
>One could build an "L-HTML" ("LISP-HTML") document looking like:
>(HTML
> (HEAD
> (TITLE "Title of document"))
> (BODY
> (H1 "Header 1")
> (P "Here's a paragraph...")))
>
>Which corresponds *precisely* to:
><HTML>
><HEAD>
><TITLE>Title of document</TITLE>
><BODY>
><H1> Header 1</H1>
><p>Here's a paragraph...</p>
></BODY>
></HTML>
>Once the document has been turned into the form of the LISP
>list, it can readily be broken up and analyzed however one
>might wish.
>The "HoTMetaL" HTML system uses this approach.
This is very interesting. Tell me more.
1) How would you represent raw text (PCDATA) with embedded tags, e.g.
some bold text inside a plain paragraph?
The SGML for this could look like
<P>This is a <B>very</B> interesting topic.</P>
2) DTD's probably are represented in LISP lists also. How?
Bart Lateur
bart.me...@tornado.be
bart.me...@tornado.be (Bart Lateur) writes:
> 2) DTD's probably are represented in LISP lists also. How?
see
ISO/IEC 10179:1996 Information technology - Processing languages -
Document Style Semantics and Specification Language (DSSSL).
Especially clause 9 (groves) may be interesting for you. Groves can be
used to represent SGML documents along with their DTDs. As DSSSL uses
a functional approach with a Scheme-lookalike, I suspect it would be a
good starting point for a stab at a LISP interface.
Goodbyte, Gerd.