If you prefer not to use ICADD atts, then simply ignore them.
Yes, we did consider the fact that parsers that support LINK
could overlay the ICADD atts, but since most parsers do not
support LINK, we did not feel that it was an acceptable approach.
We are doing the right thing. Absolutely the right thing.
Sans doubt.
Murray
>
>
> I don't mean to beat a dead horse but it does keep standing up for no good
> reason.
>
> 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
>