The transition to ICADD

"Daniel W. Connolly" <connolly@hal.com>
Date: Fri, 9 Sep 94 03:27:59 EDT
Message-id: <9409090726.AA02597@austin2.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: 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 
>T> semantics.

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:

> The
>fact that they overlap by >90% at least means that the constructs are
>somewhat universal, which is the way it should be.


Dan