The discussion this week culminating in adding ICADD fixed entity attributes
to the DTD overlooked several points that were raised in other forums. If
those points were addressed I guess I missed the the exchange.
Adding ICADD to the 2.0 DTD is not "completely noncontroversial" (as Terry
said), the technical proposal is not entirely ready to go, and although I
see statements of urgency no one has explained why this is urgent for *this*
spec.
IMHO, with some perspective on how SGML applications actually work, ICADD
(and just about any other discussion of formatting or other processing
beyond browsing by Mosaic clones) is a complete red herring at this time.
The ICADD fixed entity values are just cruft in the DTD, dead weight that
will be hard to expunge in the future. I truly don't care *how* the HTML DTD
does or does not support ICADD, except that the DTD is kind of weighty already.
ICADD attributes have absolutely nothing to do with current practice in
HTML. There should be a time and a place for discussing enhancements in the
2.1 or 3.0 review process.
There is a technical disagreement in progress, and consumers of parsed SGML
have some stake in the outcome. At least a few people share the opinion that
using #FIXED entity values is suboptimal SGML design for this or other
processing / formatting applications that are not completely central to the
purpose of HTML. IMHO it's bad practice and should not be encouraged for any
ancillary purpose no matter how socially useful.
Anyone who wants to parse HTML documents for this application *now* can add
the entities themselves *now*. (Unless the application is processing
pre-parsed SGML in some kind of ESIS repository? Hmm, I doubt it.)
A year or so from now, presumably long before some critical mass of HTML
documents has been produced, SGML parser support for LINK can be used. Also,
James Clark made a recommendation for the DTD that should be considered.
(Did anyone respond to his suggestion?)
Surely this (admittedly minor) controversy demonstrates that the technical
proposal is not "ready to go"?
So my recommendation is: do no harm now. Defer the "issue" for a short time
(one or two cycles of the DTD). All prior existing (2.0) documents are now,
and would remain, processable as SGML with ICADD applications in mind.
(Aren't they?? If I am wrong about this someone please explain.) Older
parsers can be given the fixed attributes as input in the document
declaration subset (can't they??). Applications with better / newer parsers
can use LINK types; someone should work up a proposal for the SGML code to
do this right. Eventually the HTML WG can "do the right thing" to establish
*guidelines* for HTML to serve the purposes of transformation applications
like ICADD.
But the 2.0 DTD doesn't have to canonize any one technique now. Changing the
ICADD support later would requires changing the HTML DTD later. Why do so?
. Keith M. Corbett . Special Form Software . Ask me about HyView
. kmc@specialform.com .. 53 Farragut Road .. document systems for
.. 617.596.7021 ... Swampscott MA 01907 ... HTML and Interleaf