Re: ICADD elements in HTML
Terry Allen <terry@ora.com>
Date: Thu, 8 Sep 94 16:32:43 EDT
Message-id: <199409082028.NAA06632@rock>
Reply-To: terry@ora.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Terry Allen <terry@ora.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: ICADD elements in HTML
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
| In message <199409081944.MAA05255@rock>, Terry Allen writes:
| >There seems to be consensus that adding the elements is the way
| >to go;
| I disagree. So much for consensus!
Okay, I'll make the remarks I promised to hold off for a meeting.
| > so I say we might as well put them into 2.0 as wait for
| >2.1.
| I STRONGLY disagree. Show me three major browsers that support ICADD
| documents, and I'll support a change to HTML 2.0.
Good argument.
Here's my view: HTML is basically a set of online presentation
semantics. ICADD could have been a set of abstract, nonvisual
presentation semantics, but it has followed Braille (am I right,
Yuri?), which, most interestingly (if I'm right) followed a print
model or metaphor or whatever you call it.
It would probably be a Good Thing for HTML to rise to a somewhat
higher level of abstraction, in the process incorporating some
of the more abstract semantics that ICADD could have had. It
would then be a generalized set of presentation semantics,
and there would be a set of recommendations for VT100
and GUI rendering; other sets of recommendations would deal
with Braille, etc., rendering---all from the same HTML instance.
Now if we just slot in the five ICADD elements, we are adopting the
print model without change, and we're not rising to a higher level
of abstraction, just folding in the print-specificity of Braille.
We would do better to ask what the nonprint semantics of these ICADD
elements are, and fold *those* in if need be. If we could cover
all the cases Yuri raises, on that abstract level, then ICADD
docs could run on appropriately modified WWW browsers, and even
get satisfactory visual rendering.
But Dan makes a good point that WWW browsers as they are will show
ICADD DTD documents (not as garbage but probably as) plain text,
complete with markup. I don't think that need lead to chaos.
But if HTML gains the abstract semantics needed to incorporate
the ICADD elements, then ICADD docs can be filtered to this
version of HTML trivially, and we need not bother with the
aliasing method.
So Sidebar is perhaps a kind of block-linked-to-document rather
than block-linked-to-point, perhaps something else. The page reference
elements are tougher, but if the translation is from ICADD to HTML,
then they can be managed as A's with some generated text if need be.
Either way (running two DTDs or only one), it would be interesting
to get more abstraction by encompassing the abstract semantics
of the ICADD elements; it would not be interesting to just slot
them in as is.
But if that's a reasonable way forward, despite my agreement
with Dan's arguments I could go with it, on the assumption that
we're going to clean things up later on.
--
Terry Allen (terry@ora.com) Editor, Digital Media Group
O'Reilly & Associates, Inc. Sebastopol, Calif., 95472