Re: Spec of the ALTifier project

Some initial reactions on reading through Michael's document:

** Strategy

The document talks about three "frontends:" I would call these
"representative applications" or insertions of the backend
technology.

1. Fully decisive ALT insertion as a batch transform on an HTML
document.  Demonstration is by HTTP proxy server which applies
the transform.  [Note: I would rather call this BATCH mode that
USER mode because of the TRY HARDER concept in interactive user
scenarios.]

2. [Un*x] command-line tool for site-wide ALT maintenance.
	
3. Interactive "site-wide" Windows GUI tool.

The third scenario is one that Michael Pieper's student is 
also addressing, if I remember correctly.

I believe that there are other scenarios that the ER IG might
give a high priority or the WG might be able to support with
code such as integration into a Bobby report.  I hope we can
talk some about the shape of application scenarios for the
central "novel" module in this project which is the guess
generator.

There are ER-IG issues about the expected utility of different
application configurations such as OCR, and ER-WG issues about
how can we use existing code such as Bobby as
demonstration/evaluation harnesses for new code by swapping
resources.

** Tactics:

[editorial] in the discussion of OBJECT repair it says "setting
title only for the innermost" and it may be misunderstood unless
you expand to "setting the TITLE value as the content ony for..."

[detail] changing a bare ALT with no value indication to ALT=""
is a repair that may be automatic in some circumstances and not
others.  I am suggesting that we separate candidate-generation
methods such as this which are entirely determined by the
resources found from "are we done?" rules which vary from
application scenario to application scenario.

[integration - ER-WG?] I am concerned that the PI to the A-Prompt
works at too local a level to move the "guess" function in under
the A-prompt call.  The "guess function uses more global information
than the A-Prompt call gets.  For methods experimentation, I would
think of a shared HTML --> DOM --> HTML environment or abstract
PI to a variety of such environments as a foundation for integrating
experimental transforms.  This would leave the transforms operating
on the DOM interface.  Is this something we can do?  Nobody in
this group has yet come forward spontaneously working that way.

[bias] As PF chair, I want this experiment capability to grow into
something where one can prototype propsals that we offer to W3C
working groups such as how the DOM should implement semantics that
is in a schema and not an XML DTD (except by reference).

Al

Received on Thursday, 10 December 1998 12:11:14 UTC