Re: Functional Request for DOM

Jill,

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

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.",
Frost



                                                                                                                                        
                      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                                                 
                      w3c-wai-ua-reques                                                                                                 
                      t@w3.org                                                                                                          
                                                                                                                                        
                                                                                                                                        
                      04/03/2002 02:04                                                                                                  
                      PM                                                                                                                
                                                                                                                                        
                                                                                                                                        



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

1. A guarantee that the DOM, once obtained, is valid. Using certain user
agents,
a node may
actually be the child of two parents. This is the result of invalid HTML,
but
from our perspective that makes no difference as it is impossible to work
with
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
were
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,
using
certain user
agents, to obtain a pointer to a DOM that is not complete. It would be nice
if
we could reliably determine partial completion so that the entire DOM would
not
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
interface.

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

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
curious
to know how many realistic projects are under construction in each
language.

As an aside here is what we don't need:
A tree structure. The fact that DOM is a tree might be a significant
limitation
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
invalid
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
changing
and presenting us with nothing but valid documents. A simpler design that
was
correct more often would be better.


Pat Brannan and Jill Thomas


ION Systems, Inc.
jill@ionsystems.com
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