The transition to ICADD"Daniel W. Connolly" <firstname.lastname@example.org>
Date: Fri, 9 Sep 94 03:27:59 EDT
From: "Daniel W. Connolly" <email@example.com>
To: Multiple recipients of list <firstname.lastname@example.org>
Subject: The transition to ICADD
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
In message <m0qiyyR-000ES4C@sq.com>, Yuri Rubinsky writes:
[Lots of good stuff.]
Yuri makes his points well. We are narrowing the gap... consensus
is right around the corner, I feel.
It is clear that the benefit of supporting ICADD in the web so far
outweighs the cost that it will happen. Now the question is: how?
We have Dan's proposal:
>D> Proposal: Integrate into WWW support for documents marked up with the ICADD
>D> DTD by specifying a new content type: text/icadd, and explaining
>D> to browser implementors that it can be supported using nearly
>D> the same code they use to support HTML. For example, we could
>D> add a text/icadd->text/html conversion module to libwww as a
>D> reference implementation.
and Yuri's porposal:
>Proposal: a) Add support in HTML 2.1 or 3.0 for 3-5 new elements
> in the base set, that is, for AUTHOR (AU), LIST HEADING (LH)
> and SIDEBAR (BOX); for completeness, PAGE REFERENCE (PP) and INK
> PRINT PAGE NUMBER (IPP) also.
> b) Encourage browser-makers to allow aliases for those
> elements whose ICADD names and HTML names are isomorphic.
Yuri writes about Dan's proposal:
>So that's why this seems too much complexity to me.
I suggest that neither is more complex. For example:
>Bill Perry writes:
>BP> I have been thinking of good ways to implement generic, user-specified
>BP> content-type -> content-type filters in the emacs-w3 browser.
We can look at this as if Bill is adding text/icadd support by
converting text/icadd to text/html. Or we can look at it as
"allowing aliases." Either way, it is the same "one hour" of work.
"Creeping featurism" was a poor choice of terms. I am not so concerned
with adding page number idioms or even a sidebar (PLEASE! a <NOTE> or
<ADMONITION> tag while we're at it!) element as maintaining these
aliases. The burden on documentation, support, Q/A, and maintenance
must be considered. It's just plain bloat.
But, for the cost of this bloat we get ICADD support. Small
price to pay, I suppose. I dunno.
On this point:
>D> Furthermore, I suspect that ICADD and HTML are not so similar in
>D> practice as they are in theory. Each has its own domains of
>D> application, and it's not clear to me that they are "drop-in"
>D> replacements for each other.
>I disagree with this. After 3 years of ICADD-interest, I'm still
>happy to report that head-levels, paras, lists, etc remain the
>basic building blocks of on-line, braille, spoken and print text.
I will take your word for it. (Do send me the DTD so I can
get some warm-fuzzies of my own, please.)
The only remaining critical issue for me is graceful deployment.
We do a great disservice to the Web community when we change HTML
in a way that pulls the rug out from under folks. With format
negociation in the architecture, there is no excuse for this.
We agree on this much:
>I don't think
>we'll add the ICADD elements all by themselves, but likely make them
>at the same time we do something else. All the negotation would
>exist anyway; ICADD doesn't make that process any more difficult.
But we must examine the scenarios carefully: if we say to users
that "ICADD documents are now acceptable as HTML documents" then
we may very well have folks putting ICADD markup in a file called
"foo.html" . An HTTP server may very well serve this up as text/html
with no distinction from previous versions of HTML. Old browsers
will make a mess of these documents (ignoring <PARA>, rather
than treating it as <P>, for example). Sadness.
If, on the other hand, we say "Most web browsers now support
ICADD documents" and we instruct server administrators to
map the extension .icadd to text/icadd, then the new browsers
work well, and servers can detect a lack of support for text/icadd.
A server might, in that case, invoke a server-side translation
from text/icadd to text/html.
Granted, the scenarios are technically very similar. Servers can
down-translate HTML 2.1 to HTML 2.0 as well.
But in practice, I believe my proposal will result in higher
reliability and hence higher perceived quality.
On a more academic note...
>T> Here's my view: HTML is basically a set of online presentation
Yuri expands on this:
>Rather they use SGML really as a way to formalize the specification
>of display capabilities. Admittedly they do so by specifying a basic
>set of logical structures, but in a sense that's only because it's
>convenient to do so.
>HTML will never include <TASK> or <SUBTASK> for airline maintenance
>manuals; it will never include <PARTNO> or <ACCESSIBILITY-CODE> or
>other content-driven or semantic-driven encoding. Neither will
>ICADD. They're both concerned about the basic representation of
>either simple or complex documents using simple constructs.
I've never been comfortable with describing HTML as "a presentation
DTD." Rather, I look at HTML as capturing the most common communications
idioms. A heading, list, or paragraph is not necessarily a visual thing.
The conventional printed representation of these idiom is so pervasive
that we don't even see it.
Yuri says it best:
>fact that they overlap by >90% at least means that the constructs are
>somewhat universal, which is the way it should be.