Re: HTML 2.0 Scope

Murray Maloney <murray@oclc.org>
Date: Wed, 6 Jul 94 10:10:59 EDT
Message-id: <9407060949.aa01538@dali.scocan.sco.COM>
Reply-To: html-ig@oclc.org
Originator: html-ig@oclc.org
Sender: html-ig@oclc.org
Precedence: bulk
From: Murray Maloney <murray@oclc.org>
To: Multiple recipients of list <html-ig@oclc.org>
Subject: Re: HTML 2.0 Scope
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Implementation Group (Private)
I don't specifically recall what was in Yuri's version,
so I can't comment on that, but...

I did notice one thing that seems to be missing -- although
it is not really something that can be generated automatically
from the DTD -- and that is a brief official name of the element.
I have two purposes in mind for this...

First, by having an official name for each element -- not just
its syntactic name of <P> or <H1>, but "Paragraph" and "Heading,
Level 1" -- it will make it easier for everyone to discuss
this DTD without resorting to phonetic pronunciation of tags.

Second, I recall that in A/E (and HoTMetaL, presumably) there 
is an association between tag name and a brief descriptive name.
When you select a tag from a dialog list in A/E, you see the 
short SGML syntactic name of the tag in one column and this
descriptive name in the adjoining column.  I assume that other
SGML applications do this as well, or that they will in time.


Now, this may sound like a weird idea -- I'm not sure if it
appropriate or not -- but perhaps we could attach an IMPLIED
attribute to every element that is set in the DTD to the 
short descriptive name discussed above.  Since it would be
an IMPLIED attribute, we wouldn't need to worry about current
practice getting in the way, and nobody ever needs to use
it in their documents.  But it would be there in the DTD
as an architectural form that could advise an application.

Murray
> 
> If there's anything in Yuri's document that should be in the spec
> (i.e. http://www.hal.com/%7Econnolly/html-spec/L2index.html) but
> isn't, let me know.
> 
> If his is "just plain better" in spite of the maintenance issues
> above, we can look at ways to integrate his version in the spec.
> 
> Dan
>