Re: The spec evolves...

Dan Connolly <>
Message-id: <>
Subject: Re: The spec evolves... 
In-reply-to: Your message of "Mon, 07 Dec 92 01:07:52 +0100."
Date: Sun, 06 Dec 92 21:55:04 CST
From: Dan Connolly <>

>I just subscribed to www-talk, and haven't been able to read all the
>previous exchanges, so please forgive me if this is inappropriate...

On the contrary... this is great stuff!!!

>>3. I got rid of the TYPE attribute on anchor tags.
>>What's that thing for anyway. Does anybody use it?
>Yes, I have the following (experimental) use for it.
>I have written a program that translates texinfo (the GNU Emacs
>documentation format, which can be typeset using a special set of TeX
>macros as well as converted to a form of hypertext called Emacs INFO
>files) to HTML.

Yea! TeXinfo is a Good Thing, and I think it's highly appropriate
that W3 support it as an authoring environment. The beauty of TeXinfo
is that it's _not_ a programming language like TeX or troff. That
makes it possible to develop correct translators. (Otherwise you
run into the halting problem... it's everywhere!)

I studied the TeXinfo documentation for a couple hours before I
released the last version of the HTML spec. The major feature
of TeXinfo lacking in HTML is character-level formatting (font

There were a few TeXinfo commands (@ctrl for one) that don't
fit the HTML mold. So I looked at the LaTeX options: em, tt, bd, sl, sf
and the DocBook options, and nroff, and decided I didn't have
time to choose the right set.

[I'm also keeping MS Word (RTF) and FrameMaker (MIF) in mind.]

>... My
>translator adds types to structured links that indicate whether it is
>a link to a child, a left or right sibling, a parent, or the root of
>the tree.  This type is then used by a special WWW browser that I
>wrote to support tree browsing operations (which are actually
>compatible with the operations of the Emacs INFO browser).  I think
>this is useful, and better than second-guessing the tree structure
>from where the links lead to.

Very true. I think the A tag is _highly_ overloaded. One click on
an anchor might take you anywhere from the next sentence to
somewhere in New Zealand. I suggested the XREF and SEE elements
to distinguish between intradocument and interdocument references.

I agree that a "relationship" attribute to the XREF element would
be useful.

But I'm not sure it should go in the HTML spec. I think the spec
currently does a pretty good job of describing the current usage
of HTML. Your use of TYPE is local to your site. It could just
go in the category of "tolerated error."

Meanwhile, I think it's time to redesign HTML. I've been reading
up on HyTime, and I think it's a Good Thing after all. I think
we should make the Universal Resource Locator a HyTime architectural
form. In general, we should use HyTime as a way to guide the
architecture of W3, so that it may grow to interoperate with
for example, the Draft Advisory Standard on Hypertext (DASH)
from the Davenport group.

>BTW, the results of my conversions (applied to several standard Emacs
>manuals as well as to documentation for Python, the language I'm using
>to write all my software in)

Python -- I read a bunch of stuff about that a while ago. I wonder
if the Midas language used by the Midaswww browser could be subsumed
by Python. Aside from the pascalish syntax, I think Python is just
what we need: an object oriented language for distributed applications.
I've been hoping GNU smalltalk would mature, but maybe I should
look at Python again. Tony: have you heard of it?

Hmm... as I study the documentation, I see it's got all sorts
of good stuff: exceptions, packages, regexp processing...
Maybe I should abandon XLisp (that's what I've been writing
translators in) for Python.

>I have added all sorts of other tags and attributes that don't exist
>officially but which my own browser supports (e.g. font changes).
>Later I'll try to catch up with the current proposals for HTML and
>use that instead.  I might also suggest other changes from which my
>texinfo conversion might benefit.

I highly suggest you grab the sgmls parser and diddle with the DTD
until you find something that matches the output of your conversion.
You'll have to struggle a little while you learn about SGML, but
that's the whole point. I think you'll catch on fast.