Re: Adding new tags (was: Redefining...)

Daniel W. Connolly (connolly@hal.com)
Mon, 13 Jun 1994 14:46:25 -0500


Message-Id: <9406131946.AA10830@ulua.hal.com>
To: jenglish@crl.com
Cc: Multiple recipients of list <www-html@www0.cern.ch>
Subject: Re: Adding new tags (was: Redefining...) 
In-Reply-To: Your message of "Mon, 13 Jun 1994 21:07:31 +0200."
             <199406131903.AA15666@crl.crl.com> 
Date: Mon, 13 Jun 1994 14:46:25 -0500
From: "Daniel W. Connolly" <connolly@hal.com>

In message <199406131903.AA15666@crl.crl.com>, Joe English writes:
>
>timbl@www3.cern.ch wrote:
>[Re: <RENDER> and new elements]
>> So are we assuming full DTD parsing is mandatory for all HTML+
>> clients of 3.0+?  If so, you are getting quite bogged down in SGML
>
>This is a good point.  
>
>If HTML+ allows new elements to be declared in the
>internal DTD subset, then browsers will pretty much
>have to incorporate a full SGML parser.  

Not so. If you let documents say:

	<!ENTITY % cextra "| quark | lepton">

but you keep the element declarations in the pre-compiled
part of the DTD, e.g.

	<!ENTITY % cextra "" -- user extension -->
	<!ENTITY % phrases "EM | STRONG | %cextra">
	<!ELEMENT (%phrase) - - (#PCDATA | A | %phrase)>

then you can introduce this "hook" processing without complicating
the browsers' parsers terribly.

>Also, the current proposed mechanism for defining new
>elements (the "?extra" parameter entities) requires that 
>all browsers are based on the same DTD -- a goal worth 
>working for, to be sure, but not likely to be realized
>any time soon IMHO.

Again, I disagree. The 2.0 DTD is relatively stable, and should be
publised in three months or less, with support from a number of
browser vendors. Once that happens, there will be a clear path
from the 2.0 DTD to future DTD's (I hope :-).

>Architectural forms would be much simpler to handle.

I think that architectural forms are the way to go, but I hardly think
they simplify matters. Architectural forms are a way to apply
semantics to arbitrary DTDs. They are designed for the specific
purpose of systems with full SGML parsers.

The way you've marked up your example is interesting though...  it
switches the tags and the attributes. The way you've done it, you
could never define your own content models. So the "role" attribute
acts like a "style" attribute mostly.

><p role=imho>
>I like the name <em role=attname>ROLE</em> 
>better than <em role=attname>STYLE</em>,
>since presumably this attribute conveys more than 
>just presentation information.
>I remember seeing this attribute on the 
><em role=elname>EM</em> element at one point; don't know
>what happened to it.
</p>

Using architectural forms the way HyTime uses them, this
would be:

<imho role=p>
I like the name <attname role=em>ROLE</attname> 
better than <attname role=em>STYLE</attname>,
since presumably this attribute conveys more than 
just presentation information.
I remember seeing this attribute on the 
<elname role=em>EM</elname> element at one point; don't know
what happened to it.
</imho>

And actually, none of the role=... attributes would show up in
the markup of the instance -- they'd be FIXED attributes in 
the DTD.

Dan