Re: ICADD support in HTML 2.0 - not urgent, not ready to go

Terry Allen (terry@ora.com)
Mon, 5 Dec 94 18:40:35 EST

| 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.

What's this technical proposal that's not ready to go?

| 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.

huh? enables access for the print-disabled. Applications already exist.

| 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.

Ignore them then.

| 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.

I repeat, applications already exist.

| 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.

Let them eat cake?

| 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"?

Eh? ICADD is set up to use fixed atts, not LINK. Fixed atts work
with sgmls and SP; LINK doesn't.

| So my recommendation is: do no harm now. Defer the "issue" for a short time

Exactly. We add in the atts to help the print-disabled; you are free
to ignore them in the ESIS.

| (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.

It's a fixed, agreed-upon set of ICADD atts that is desired. Thus the
push to put them in 2.0. Beyond that, 2.1 and 3.0 may or may not
achieve success; HTML as formalized by 2.0 is already here.

| (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.

We are doing the right thing.

-- 
Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
Editor, Digital Media Group    103A Morris St.
			       Sebastopol, Calif., 95472
A Davenport Group sponsor.  For information on the Davenport 
  Group see ftp://ftp.ora.com/pub/davenport/README.html
	or  http://www.ora.com/davenport/README.html