- From: Daniel W. Connolly <connolly@hal.com>
- Date: Mon, 13 Jun 1994 14:46:25 -0500
- To: jenglish@crl.com
- Cc: Multiple recipients of list <www-html@www0.cern.ch>
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
Received on Monday, 13 June 1994 21:46:32 UTC