RE: TAW Checker approach

I'll add my apologies for not pushing this along over the last week or so, and my thanks to Sean for offering to set up a call on Monday, which I look forward to attending. 

A couple of thoughts about the nature of the call:

a) I propose that Sean chairs the meeting in line with his general theme on 'ownership'

b) clearly we need an agenda and I agree with Sean's list below, with the addition of a couple of items:

i) should we set about creating a requirements document to be clear what we are trying to achieve? How/who/what/when?

ii) if it doesn't come out of i) above what is the decision process to be regarding how to decide between a declarative / XSLT approach and a procedural / Java based one?

iii) I think a Face to Face meeting would be very helpful. It would be useful if we could decide on whether there is consensus on this, and what might usefully be achieved at it (and hence what has to get done before it).

c) can we use Zakim/IRC for this call?

regds
Jo

> -----Original Message-----
> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> checker-request@w3.org] On Behalf Of Sean Owen
> Sent: 22 February 2007 16:45
> To: public-mobileok-checker@w3.org
> Subject: 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 Friday, 23 February 2007 13:12:50 UTC