W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2002

Re: Functional Request for DOM

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Wed, 3 Apr 2002 17:16:29 -0600
To: Jill Thomas <jill@ionsystems.com>
Cc: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>, w3c-wai-ua-request@w3.org
Message-ID: <OF07AB7C96.B3143611-ON86256B90.007F0CE9@raleigh.ibm.com>

As for error correction, we have a number of server-based transcoding
projects where the DOM is created with error correction performed and
reflected in the DOM. As for creating an incentive for developers to go
back and fix there HTML sites you can forget it. The main browsers, IE and
Netscape, have already put in so much bug fixing that the situation is
irreversible unless you go to XML. In the last meeting Microsoft had stated
that Microsoft would no-longer correct document errors in XML. ... This is
fantastic. It does not fix the HTML problem.

We are looking at C++ support for the DOM in the UNIX accessibility work.
It has nothing to do with JavaScript.

As for performance, Home Page Reader uses the DOM just fine.


Rich Schwerdtfeger
Senior Technical Staff Member
IBM Accessibility Center
Research Division
EMail/web: schwer@us.ibm.com

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",

                      Jill Thomas                                                                                                       
                      <jill@ionsystems.        To:       "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>                                      
                      com>                     cc:                                                                                      
                      Sent by:                 Subject:  Re: Functional Request for DOM                                                 
                      04/03/2002 02:04                                                                                                  

As discussed in the teleconference on March 28th I am enclosing a list of
functional requirements ION Systems has using the DOM:

1. A guarantee that the DOM, once obtained, is valid. Using certain user
a node may
actually be the child of two parents. This is the result of invalid HTML,
from our perspective that makes no difference as it is impossible to work
the invalid DOM.
If a DOM is invalid as a result of incorrect input, then we need a way to
discover the errors so that the user can be presented a warning. If this
implemented, HTML authors might actually be informed that their sites were
invalid and might have some incentive to fix them.

2. A consistent method for determining DOM completion. It is possible,
certain user
agents, to obtain a pointer to a DOM that is not complete. It would be nice
we could reliably determine partial completion so that the entire DOM would
have to be constructed before our software started.

3. Access to the text of the document via a consistent interface.

4. Access to the attributes, in order, of each element via a consistent

5. Access to the parent tags, in order, of each element via a consistent

6. A C++ binding. Java and Javascript are great, but they don't make the
cut for
many performance critical or mass distributed applications. ION would be
to know how many realistic projects are under construction in each

As an aside here is what we don't need:
A tree structure. The fact that DOM is a tree might be a significant
to its architecture. Users do not see the document as a tree, they see it
as a
list. Having the DOM as a tree makes creation of a valid object from
input more difficult  and also makes it harder to render. This may be an
off the
wall suggestion, but included it anyway because our primary problem with
DOM is
getting one that is broken, and we don't see the world of HTML suddenly
and presenting us with nothing but valid documents. A simpler design that
correct more often would be better.

Pat Brannan and Jill Thomas

ION Systems, Inc.
636-937-9094     Fax 636-937-1828
107 Mississippi Ave., Crystal City, MO 63019
www.ionsystems.com     Your Bridge To Usability
www.galaxylibrary.com  Where Electronic And Print Worlds Converge
eMonocle (tm) an XML viewer for simultaneous use by sighted, low vision
and, in
the near future, blind readers.
Web Eyes (tm) a web plug-in facilitating compliance with Section 508 and
accessibility to any web page for low-vision users.
Received on Wednesday, 3 April 2002 18:16:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:32 UTC