Re: TAW Checker approach

Thanks Miguel. Sorry everyone I have not been helping drive progress
here lately.

So, we have some medium-sized differences of opinion about how to
structure the reference implementation but nothing that can't be
resolved. As I see it, here are the key "proposed resolutions" from
the previous thread on this topic:

1. Implementation should produce an intermediary DOM / XML document
2. Some tests should be implemented as XSLT transformations
3. The test output should be made available as a detailed DOM / XML document

I share Miguel's concern about the cost versus benefit of 1 and 2, but
support 3. I hear at least two voices in support of 1 and 2 though.

Miguel, can you share any of your TAW code? the design of a working
implementation may be useful for everyone to see.

How to proceed? First, let's have that call we were talking about. How
about 10am EST / 4pm CET, Monday, February 26? If anyone has an easy
way to set up a conference bridge, go ahead. If I hear nothing I'll
figure out how to set one up tomorrow.

The key questions, in my view, are:

A. We have three relevant implementations (Dom's, .mobi, TAW). I've
gone off and started defining a fourth. Are we comfortable with that?
The fourth implementation's goal is to be independent of anyone's
particular usage or deployment, but, also conceivable usable by the
W3C and .mobi and TAW.

B. Ownership. Things get done when they have owners, and in software,
one architect is good. I have the time and willingness to drive this,
but, am concerned I won't fairly represent the design goals of
everyone (in particular regarding points 1 and 2 above.) So... who
else wants to work a lot on this and can start writing code?

C. Find a resolution to items 1, 2 and 3 above.

D. Next milestone -- what can we do before the final release of
mobileOK Basic Tests 1.0


Sean


On 2/16/07, Miguel Garcia <miguel.garcia@fundacionctic.org> wrote:
>
> Hello everybody and sorry about the delay.
>
> We have had a lot of work in other issues so we haven't answered before. We'll explaining the approach of TAW checker in relation with the ideas discussed in the list and share some thoughts.
>
> We think the declarative approach could give more extensibility and portability than a language specific library. But like Sean said before, the generation of the meta document can't be made in language agnostic way so the portability is not 100% possible. Also we think that this developing (defining metadoc, share the work, put all together) would be much more expensive that the Sean Java library. Which would be the desirable date to get the reference checker?
>
> In TAW checker we opted for a Java library (similar to the prototype offered by Sean), we'll explain in more depth in another mail.
>
> In addition we want to add some commentaries based in CTIC's experience developing TAW. Just note TAW was originally conceived as an a web accesibility (WCAG 1.0) checker tool and the solutions were taken with that aim in mind.
>
> Our first problem was the majority of web pages are not well formed so we first thought about using a source repairer tool. But we discarded source repairer based solutions because of the traceability of the errors or warnings. If you are a user you want to know where is the problem that is which element caused it and where is inside the source code. An option is maintain a map between original source code and repaired code. We opted for instead of using DOM parsers use another parser, specifically HTML Parser library. A LGPL library for parsing (x)HTML documents that doesn't require a well formed document.
>
> Perhaps it would be better to combine both solutions, if the document is well formed create a DOM tree otherwise enter in a 'quirks mode' and use a HTML parser.
>
> If a repair tool is used, ¿all the checkers should use the same tool in order to generate the same results?.
>
> Next we have some dificulties with encodings. Sometimes documents are not encoded as declared and these could lead in fatal errors during parsing. So we do a preprocessing to detect the real encoding of the document before parsing it.
>
> Regards
>
> ******************************************
> Miguel García
> Fundación CTIC
> -Centro Tecnológico de la Información y la Comunicación-
> E-mail: miguel.garcia@fundacionctic.org
> Tfno: +34 984 29 12 12
> Fax: +34 984 39 06 12
>
> Parque Científico Tecnológico Gijón-Asturias-Spain www.fundacionctic.org
> ******************************************
>
>
>
>
>

Received on Thursday, 22 February 2007 16:45:45 UTC