Re: New Topic: HTML and the Visually Impaired [long]
Murray Maloney <murray@sco.COM>
Date: Thu, 8 Sep 94 09:11:19 EDT
Message-id: <9409080901.aa06146@dali.scocan.sco.COM>
Reply-To: murray@sco.COM
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Murray Maloney <murray@sco.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)
Thanks to both of you for helping to make this
so much clearer. However, I am still a bit
confused about what you do and don't agree on.
I think that I have to go along with Yuri's
argument for subsetting ICADD into HTML.
I would like to understand the detailed
specifics of the proposed new elements
and added attributes, but I agree in principle.
In Geneva -- where I will see you all again someday
I am sure -- we agreed that WWW browsers should
move toward supporting additional specific DTDs in the
not-too-distant future. I was thinking of DocBook
at the time -- and I would still like to see that --
but I am persuaded by Yuri's arguments that it would
be fairly easy to implement support for ICADD as a true
subset of HTML. More than that, I think that it
is the "right thing" to do.
Murray
>
> I hope this is actually of interest to more than just Terry
> and me. At any rate, I think we're moving towards a clearer explanation
> of what would actually be required. In practical terms, all I hoping is
> to add five elements to the Proposed list. Everything else is up to the
> browser implementors; we could recommend the aliasing of isomorphic
> elements from ICADD to HTML, that's about all. I thank Terry for the fact
> that I now have this much more succinct view of what's needed to enable
> the print-disabled population to successfully interoperate with the Web.
>
> It's probably about the right time to call for a show of hands. If enough
> vote in favour, I'll create the appropriate text and when the draft spec
> is in my hands, add the bits before sending it on to the next editor.
>
> I apologise for the delay; I will try to finish the tables stuff off tomorrow.
>
> (Responding to Terry's responses is kind of a full-time job!)
>
> (meant in the best possible way...;-)
>
>
> ===================
>
>
> Terry writes, quoting my previous mail:
>
> > | In effect, since ICADD-tagged files
> > | can be created from *any DTD with the fixed attributes* this would
> > | allow any documents conforming to such DTDs to be rendered using
> > | WWW browsers without having to convert them *both* into HTML and
> > | ICADD. (The latter is what UCLA now does with its campus-wide
> >
> > But if the HTML DTD has these atts, then conversion into HTML only
> > would suffice.
>
> Almost. The difficulty comes from the fact that if the HTML isn't rich enough
> to support elements that are in the ICADD DTD but not HTML, then there
> are problems for the Braille. (This is why, in a sense, we need so many
> DTDs on the planet.)
>
> For instance: Let's flog this sidebar a bit more. A textbook publisher
> has a document with sidebars. There is a concept of a sidebar in the
> Braille output as well.But we're asking them (if I understand Terry's next
> comment correctly) to encode the file in HTML rather than ICADD.
> So the fact that such-and-such is a sidebar gets lost, turned into
> a paragraph perhaps (for display only) rendered as a pointer to a
> separate file, perhaps as text set off by HR elements before and
> after. However, the critical thing from the point of view of the
> Braille renderer (and the large print version for that matter) is that
> this was a sidebar and that fact is now lost. We've down-translated
> too early, so to speak.
>
> Most often we down-translate to HTML, and expect that that is the
> last point of transformation; this is where the display is going to
> happen so it doesn't matter if the fact that this was a <TASK> or
> a <PARTNUM> gets lost. Same with ICADD. But each of them
> has a richness that the other doesn't have (or need) in certain
> areas.
> >
> > | information service.) Many books, particularly textbooks,
> > | need to be transformed into the ICADD tagset in order to easily
> > | be printed in Braille or fed into synthesized voice readers (such
> > | as IBM's Book Manager which does a great job for visually impaired
> > | people). Accordingly, since that text exists in that form, it seems
> > | to me to make sense to be able to distribute those files in
> > | electronic form for use with free browsers.
> >
> > Right, but this could be in HTML instead of ICADD proper. In
> > other words, if HTML has ICADD fixed atts, it's a better presentation
> > format than ICADD-DTD-encoding.
> >
> A better presentation format for the Web perhaps, but not for
> the other requirements -- unless we add that handful of elements
> that will make HTML a true superset of ICADD! In which case,
> people creating files for Braille directly can use ICADD and those
> files will browse in a WWW browser. People creating files in
> HTML will have them down-translated into ICADD for Braille
> production and things like MENU, DIR, PLAINTEXT, META
> and so forth will get translated into Braille-appropriate formats
> using ICADD tagnames.
>
> > (Collapsing the argument a bit, as I understand it better:)
> > So you want to be able to run ICADD files through Mosaic, and
> > need a few extra elements, such as BOX.
>
> Yes.That's all it is really.
> >
> > | > | This is a sidebar. Remember that most ICADD usage is for textbooks
> > | > | which, in the modern style, are sidebar-rich. I don't think we
> > | > | can actually leave it out if we want to support ICADD files. That
> > | > | is, we have to do something with a file that has a SIDEBAR in it,
> > | > | rather than just format it as a paragraph. HTML is pretty specific
> > | > | about online presentation already. I'm not convinced that this
> > | > | <HR> approach is so out of keeping.
> >
> > I'm still uneasy about sidebars. You are suggesting, I think,
> > that the aliasing be just to HR/(P|UL|etc)+/HR; doesn't that mean
> > that we can get by without an actual BOX element in HTML?
> >
> We're mixing apples and potatoes here. I was thinking of an actual
> new element in HTML called BOX or SIDEBAR. But I was also
> thinking of how implementors might choose to represent that using
> existing capability. (HR/Petc/HR). However, there's nothing to
> prevent them going much further with the concept and
> implementing SIDEBAR as a cross-reference to text elsewhere,
> or whatever.
>
> The reason we can't get by without the actual BOX element in
> HTML is that we're trying to avoid having to do a transformation
> from ICADD. I'm talking about having a raw ICADD file readable
> in WWW browsers just as if it were HTML -- because in fact
> it would be a true subset of HTML (if you count the aliasing effects,
> but that's purely browser implementation). (That is, it's not really
> a true subset, but the effect is exactly the same. A browser would
> read an ICADD file if that file's extension was .html and as if it
> were. Perhaps it should be, in fact
>
> > Here's what makes me uneasiest:
> >
> > | If there's nothing in the HTML DTD that matches the concept, then it
> > | doesn't get used, that's all. But if it is, then it lets HTML authors
> > | use the sidebar concept (since parallel text of this sort does
> > | exist and is useful); it lets browser-makers implement, no doubt in
> > | interesting ways, such a construct; and, when an ICADD file comes
> > | along that uses BOX, it lets that be displayed.
> >
> > I see HTML as (potentially, at least) a very useful set of presentation
> > semantics for online rendering. I can imagine an online sidebar
> > as another node/file linked to the original, and would rather
> > map it that way. If the element is put into the DTD people will start
> > using it and making up renderings for it when they may be able to get the
> > same result more straightforwardly. I don't use the term "Tag
> > Abuse" often, but this would be a case of it.
> >
> If there is a stated semantic for BOX, then that's how it would be used.
> I don't believe there is an equivalent right now for that result; if there
> were I'd suggest a straight alias to that from the ICADD BOX.
>
> I think "Tag Abuse" syndrome is actually the opposite. In my mind it's
> the situation in which one uses the wrong element to achieve some
> sort of visual effect. I'm saying there is an effect we want -- the concept
> of the sidebar -- and concocting it any way but through a specific element
> would be a case of Tag Abuse.
>
> > | The State of Texas has established that textbook publishers must supply
> > | texts (by a certain date) only in SGML. They prefer the AAP Book DTD
> > | since it was designed by book publishers for trade books -- not because
> > | it has the fixed attributes. Alternatively, a publisher can use *any*
> > | DTD, insert the fixed attributes, and deliver files with ICADD markup.
> >
> > Then we're home free. As fixed atts are added to more and more
> > common DTDs, the need, even desireability, of encoding docs in
> > ICADD-DTD markup disappears.
>
> That's very true. ICADD markup is intended to be a temporary phase
> that a document passes through on its way to a Braille printer etc. It is
> absolutely *not* rich enough for storage and retrieval of valuable
> information.
>
> > Do I understand correctly from this
> > and your previous postings that while the ICADD DTD is an ISO
> > standard it's not considered fully cooked (or more kindly, early
> > revisions are considered useful)? Rather different from most
> > ISO standanrds.
> >
> It's an "informative" part of the standard and appears in an Annex.
> It intentionally leaves uncooked the table handling and the math,
> but otherwise is considered to be stable. People have built Braille
> software that reads ICADD files and people are using it in production
> today. It seems to work just fine for its stated purposes.
>
> > | All I'm hoping will happen is for HTML to include the handful of ICADD
> > | elements that don't map directly to existing HTML elements; for
> > | browser-makers to alias the handful of isomorphic elements; and for
> > | agreement from everyone (and comments thus far suggest that this *is*
> > | agreed) that we can publish HTML 2.0 with the SDA attributes built in.
> > | (That's work I'll do as whatever moment seems right.)
> >
> > I now understand much better, Yuri; let's mull over this mapping
> > problem some more and see if we can get a better result. Would it
> > be too difficult to map-on-the-fly a BOX to a new HTML instance
> > with a link to it that has "See Sidebar" as its hot spot? After
> > all, a sidebar is really only out-of-flow material, often allowed
> > to float in the context of page composition; we don't need to
> > worry about floats online, and we can reproduce the effect of
> > being out of flow by linking.
>
> No, I don't think it would be too difficult, but my position is that this
> should be a question for a browser implementor, not for a DTD writer.
> That's presentation; as far as I'm concerned, SIDEBAR is a *logical
> construct* which, along with LIST HEADING, AUTHOR, INK PRINT
> PAGE and PAGE REFERENCE, make sense in a forthcoming HTML
> -- even if only in a ICADD marked section which is defaulted to
> INCLUDE.
>
>
>
> Yuri
>
>