As far as I know, all issues were addressed. If any weren't, lets do it now.
> said), the technical proposal is not entirely ready to go, and although I
What's left?
> see statements of urgency no one has explained why this is urgent for *this*
> spec.
Making HTML available in a usable fashion for print impaired users.
> 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.
If they are not necessary in future versions, it is easy to remove. Relative
to most applications, the the HTML DTD is relatively "lightweight" not
"weighty".
> ICADD attributes have absolutely nothing to do with current practice in
ICADD is current practice for print impaired access to SGML.
> 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
LINK is not widely available ... yet. James Clark's new SP will change that
over time. It has been stipulated that LINK is good and is a long term
solution. (What about the DSSSL STTP?)
> purpose of HTML. IMHO it's bad practice and should not be encouraged for any
> ancillary purpose no matter how socially useful.
A missing sense of scale here? Before talking about encouraged besmirching,
see what kind of HTML exists out there now as current practice. We are moving
in the right direction.
> Anyone who wants to parse HTML documents for this application *now* can add
> the entities themselves *now*. (Unless the application is processing
The most used public domain parser is sgmls. The most used commercial parser
is probably OmniMark. Neither supports LINK. The future is a different story.
> 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,
There is already a *large* body of HTML. There is a large body that
will be created to HTML 2.0. There is a large body that will be created to
HTML 3.0. There is an even larger body that will be created as arbitrary SGML.
Using the SDA attrs helps now and doesn't hurt the future.
> James Clark made a recommendation for the DTD that should be considered.
> (Did anyone respond to his suggestion?)
Hmmm ... didn't see it (nor in a check of the archives.) Will email James
right now.
> Surely this (admittedly minor) controversy demonstrates that the technical
> proposal is not "ready to go"?
Most people believe that 2.0 is good for go with a few minor edits. Please
join in the next round for HTML > 2.0.
> 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 what do we tell the print impaired community now?
> parsers can be given the fixed attributes as input in the document
> declaration subset (can't they??). Applications with better / newer parsers
It's a no-no to doubly define <!AttList ...>
> 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
See Steve Pepper's work on this (LPD for ICADD).
> *guidelines* for HTML to serve the purposes of transformation applications
> like ICADD.
See the DSSSL Lite and STTP.
> 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?
SDA is the current practice today to provide access. In the future we'll use
LINK, DSSSL STTP, etc. Please help by writing an LPD for SP, a scheme app for
DSSSL STTP and joining the discussion.
> Why do so?
For now, it's the right thing to do.
Jeff Suttor
JSuttor@Library.UCLA.Edu
Voice: +1 310 206 5565 Fax: +1 310 206 4109
<URL http://WWW.Library.UCLA.Edu/~jsuttor/jsuttor.html>
Member of IETF HTML-WG (http://www.hal.com/%7Econnolly/html-spec/)
Member of SGML Open (http://www.sgmlopen.org)
Davenport Group Groupie (http://www.ora.com/davenport/README.html)