Re: New Topic: HTML and the Visually Impaired [long]
"Daniel W. Connolly" <connolly@hal.com>
Date: Thu, 8 Sep 94 15:13:57 EDT
Message-id: <9409081911.AA00246@ulua.hal.com>
Reply-To: connolly@hal.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: New Topic: HTML and the Visually Impaired [long]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
Proposal: Integrate into WWW support for documents marked up with the ICADD
DTD by specifying a new content type: text/icadd, and explaining
to browser implementors that it can be supported using nearly
the same code they use to support HTML. For example, we could
add a text/icadd->text/html conversion module to libwww as a
reference implementation.
Proposal: Integrate support for documents marked up with the HTML
DTD into ICADD applications by adding fixed attributes to
the HTML DTD. If there is sufficient experience with this technique
at the time the HTML 2.0 document gets published, these fixed
attributes can be part of the 2.0 HTML DTD. If these fixed attributes
are not completely stable by that time, it should wait for 2.1.
Here's the situation as I see it:
There are LOTS of documents that more or less "agree" with the HTML
2.0 DTD. With a little decoration of the HTML DTD, these documents can
be consumed by ICADD-architectural-form-consuming
applications. Bingo. Slam dunk. No brainer. Win Win.
Perhaps in the near future, more ICADD applications will be
independent of the ICADD DTD, and merely dependent on the ICADD
architectural forms. Then information providers can mark-up their
stuff in HTML and have it consumed by both the Mosaic/lynx market and
the ICADD market.
Meanwhile, apparently (I have no first-hand experience here) there are
LOTS of documents marked up with the ICADD DTD, and some govenment
contracts require this markup, and so there will be more documents
marked up this way in the future. Further, the ICADD DTD and the HTML
2.0 DTD are nearly isomorphic. If you've got code to support HTML 2.0,
it's an hour's work to support ICADD DTD documents. So we want to
encourage browser implementors to support ICADD DTD documents.
One way to do this is to say "As of Jan 1, 1995, HTML includes all
the ICADD tags." Browser implementors scurry around between now and
then, and HTML includes ICADD.
But is this the forward-looking way to approach this problem? Every
time we see a new body of legacy documents, we change HTML to
incorporate those idioms?
Or do we promote the multi-format architecture of WWW? Do we encourage
folks that one day there will be native support for many DTDs --
perhaps DocBook soon, and perhaps some commercial web clients will
support arbitrary SGML documents?
HTML is a good thing. It solves some problems. It's a great foundation.
It will always be the common ground for the web.
But let us not submit it to creeping featurism. HTML should always be
the _simplest_ markup language that will let folks around the globe
communicate using hypertext and to some extent, hypermedia.
Furthermore, I suspect that ICADD and HTML are not so similar in
practice as they are in theory. Each has its own domains of
application, and it's not clear to me that they are "drop-in"
replacements for each other.
Let's add text/icadd (or application/icadd, whatever) support to some
browsers, gain some experience, see if there are any user interface
issues, and then see if HTML needs any changes.
I'm all for integrating ICADD into the web and making/keeping the
web accessible to the greatest number of people possible.
But I don't support "merging" ICADD into HTML.
If there are folks converting ICADD documents to HTML and they find
that they are making some terrible kludge that can be eliminated
by changing HTML just a little, then I'm interested to see specific
examples of this, and I'm open to suggestions on how to change HTML
to accomodate this application. That's what I meant by "making changes
to HTML to make it isomorphic to ICADD."
>From what I can see, it's already possible for ICADD-achitectural-forms
applications to consume HTML. And adding support for ICAD DTD documents
in web browsers does not necessarily imply making changes to HTML.
Dan