mobileOK checker library teleconf

Sean: mobileOK is nearing the end of Last Call
... as this is tests-based, it would be nice to have a ref implementation
... already have several tentative implementations: w3.org, TAW, Mr Dev from dotMobi
... would like to develop a 4th implementation that would serve as a reference implementation that these existing projects could use
... that's what this task force is about
... we need to look at the next steps so that we can keep up with the schedule of the mobileOK basic spec
... probably moving forward in March/April timeframe
... I have seen 3 main issues coming up in our discussions:
... 1. Implementation should produce an intermediary DOM / XML document with a bunch of information on the document retrieved
... the idea being to allow to process it through XSLT
... also, the test output should be made available as a detailed DOM / XML document
... discussions whether it's worth having an intermediate XML document at all or not

Shadi: besides EARL, the ERT WG is working on an RDF vocabulary to describe HTTP
... in terms of protocol, based on the RFC
... this allows to describe fully a web resource, including headers etc
... useful to be able to describe exactly what web resource we got from the server
... also useful for ajax-based applications

Sean: I see; allows to describe response/request, headers and body
... Makes a lot of sense to re-use that

<shadi> http://www.w3.org/TR/HTTP-in-RDF/

Shadi: we hope to go to LC with EARL and that WG note by the end of this month

<Zakim> jo, you wanted to respond to sean

Jo: probably fits, but we need to capture arbitrary http headers, not only the ones that are defined in HTTP

Shadi: we support additional headers as extensions point in our vocabulary

Jo: We would also probably want to represent both the headers as put by the client/server as well as some canonicalized version of them
... I'm not personally set about using RDF or not, as long as the requirements are met
... I think we need to focus on requirements at this point, rather on which specific format

Sean: there is some debate between procedural (e.g. in Java) vs declarative (e.g. XSLT) ways

Jo: question about whether a procedural implementation is acceptable for a reference implementation

Dom: I don't think it's a problem to focus on a procedural impelementation
... most of the work needed is procedural anyway

Sean: tend to agree with that
... I don't think we should take language-independence as a requirement, unless it's easily achievable

Jo: I think both approach can be defended

dom: agree that we need some requirements, but we also need to start coding
... needs some requirements e.g. for interfacing with applications that would rely on our library

Sean: in terms of our requirements, we're clearly basing our stuff on mobileOK basic
... we need more work on some unspecified aspects (e.g. error handling, etc)
... we also need to produce some useful output, including pass/warn/fail, but also additional informations

jo: for dotMobi, one of our big requirements is to be able to add more tests, i.e. extensibility
... an intermediary format would certainly help adding ad-hoc processing
... I'm happy to take the lead on writing up requirements

sean: agree with extensibility
... for me that implies that the output should be very rich
... (input headers, body, etc)
... but that's a separate concern from portability which I think was the main trigger behind XSLT

Jo: not quite
... we need as much information as possible somewhere available for extensions

<Zakim> dom, you wanted to explain requirements based on his experience with the checker and to take up Jo's offer on leading requirements and to ask about sharing code

dom: brain dump of what we need: what things triggered a failure (pointers, code quote), cascading errors,
... I think we should offer Jo's offer to edit requirements
... would also be nice to look at the existing code bases to identify more requirements

sean: agree
... I'm still not sure we need the intermediary requirements

<Zakim> dom, you wanted to say that the intermediary document should be trivial to produce

dom: I think producing the intermediate document should be trivial if we do our work right
... don't think we should focus on it
... I think it should be doable as a thin layer above our library
... but I don't think we need to put specific efforts on it

jo: I think we ought to put some specification effort in the manner of processing that allows to come to the conclusions that you want to take
... I think the pre-processing effort needs to be specified, whether it is done in java or in a declarative way

<Zakim> jo, you wanted to elaborate on cascading errors

jo: there are some assumptions that may need to be made when hitting non well-formed content
... e.g. how to handle a document that is not encoded in utf8
... is this something that the ref implementation should handle?
... more generally, how much the reference implementation should leave to value-added implementations?
... I think this needs to be described in requirements

<Zakim> shadi, you wanted to describe EARL pointers and invite review

shadi: going back to the discussion on cascading errors and on sources of errors
... as part of EARL, we have developed "pointer methods in RDF" which describes several ways to say what part of the tested content triggered an error
... EARL doesn't make any assumption how the tests fit in a test suite
... it assumes some atomicity of the tests cases

Sean: so EARL doesn't define tests dependency?

Shadi: right

Sean: probably not a big problem; that maybe something left to additional implementations
... I agree with Jo that the hard part will be to figure out e.g. whether a document is properly encoded or not, and this will need to be done through procedural coding
... whether this is translated into a boolean flag or into some XML markup, the added value from XSLT doesn't seem obvious

jo: "I don't disagree"
... I think it's desirable to make things as atomic as possible
... I guess the question is really whether how much XPath can offer

Sean: I don't have a strong objection to define a modular architecture
... if we say we need to define an intermediary document, I think this will roughly double the amount of work we'll need to do

dom: intermediate document could be useful as an API for code built on top of our libraries
... still think we need to focus on the hard work (work with ill-formed, ill-encoded content, etc)

sean: ok, let's give it a try

<srowen> PROPOSED RESOLUTION: test implementation will produce an intermediate representation specifying the results of accessing and evaluating ("preprocessing") a resource. This representation will be available as a DOM / XML document

<srowen> PROPOSED RESOLUTION: as many tests as is reasonable will be implemented in terms of the intermediate DOM

<srowen> PROPOSED RESOLUTION: test results will be available not only in Java API form but in a comparable DOM form expressed using EARL

[sounds good to me]

<srowen> PROPOSED RESOLUTION: reference implementation will be written in Java

<nacho_marin> no objections here

<srowen> RESOLUTION: test implementation will produce an intermediate representation specifying the results of accessing and evaluating ("preprocessing") a resource. This representation will be available as a DOM / XML document

<srowen> RESOLUTION: as many tests as is reasonable will be implemented in terms of the intermediate DOM

<srowen> RESOLUTION: test results will be available not only in Java API form but in a comparable DOM form expressed using EARL

<srowen> RESOLUTION: test results will be available not only in Java API form but in a comparable DOM form expressed using EARL

RESOLUTION: reference implementation will be written in Java

milestones, ownership

<scribe> ACTION: Jo to summarize the requirements in a note [recorded in http://www.w3.org/2007/02/26-bpwg-minutes.html#action01]

Jo: I think it's useful to spend some time on refining the requirements

Sean: I tend to agree, but I certainly want to move forward with coding

+1 to have Sean driving this

Sean: I'm willing to drive this, but don't want to take too much control
... I'm open to other persons doing this

Jo: agree with Dom about you driving this
... still think it's useful to have a requirements document in // with our code effort

[I agree that it would most useful if we could document what our code does in // to developing the code]

Sean: sounds good

PROPOSED ACTION: Sean to sketch some code matching what we discussed today

Jo: FWIW, what I have in mind is mostly a picture of what we want to do

Sean: I think I can write up what I want us to do in terms of code, illustrated with code

<scribe> ACTION: Sean to incorporate the resolutions in sketch code [recorded in http://www.w3.org/2007/02/26-bpwg-minutes.html#action02]

<scribe> ACTION: Sean to explain clearly the overall architecture [recorded in http://www.w3.org/2007/02/26-bpwg-minutes.html#action03]

Sean: maybe premature to talk about deadlines

dom: plan AFAIK is to have mobileOK basic CR end of April
... I think we should plan to have some version of our code ready around that time as much as possible

Sean: Ok, so our goal should have to something even in beta form available on the Web around that timeframe

Jo: if this is going to be promoted by the BPWG as a ref implementation, whether this goes through Rec track or not, it needs the same level of scrutinity as a rec track doc
... we also needs to consider questions regarding maintenance of the code as ref impl

<Zakim> shadi, you wanted to share similar experiences with public perception in WAI

dom: don't think we should target to be labeled as ref impl anytime soon
... although we should develop it as if it was one
... I think we can probably get the WG to talk about our implementation as part of the CR phase

shadi: yes, we have had difficulties in that regard in the past
... in WAI
... there is a difference between W3C building a tool and somebody else doing it

srowen: there is a difference between W3C implying that something is mobileOK with somebody else
... not sure about process/terminology
... don't really care about it being called "ref impl" at this time
... but would like it to be available on w3.org
... I think it should be a de facto ref impl

dom: I think if we manage to produce something better than the current checker, I don't see any reason not to replace it with the new code

jo: agreed

sean: ok, that's great

jo: would just need some caviar around it
... (incomplete, not fully tested, work in progress, etc)

<srowen> PROPOSED RESOLUTION: if implementation is as useful / robust or more so than existing checker, as decided by this task force, then we will try to use it to power validator.w3.org along with the release of mobileOK Basic Tests 1.0 in late April

<srowen> erm, let me add some text to that:

<srowen> PROPOSED RESOLUTION: if implementation is as useful / robust or more so than existing checker, as decided by this task force, then we will try to use it to power validator.w3.org along with the release of mobileOK Basic Tests 1.0 in late April. It would be heavily caveated -- that it's beta, in progress, incomplete and must only be cited as a work in progress

jo: based on previous debates elsewhere, I think we need to make it clear that things that are not tested are approved in any way
... e.g. we have had issues with Mr Dev not looking at table layouts

nacho: can se start with the procedural approach for sake of efficiency
... and look at the intermediate document later?
... so that we can make it on time for the end of April deadline

[I think that would be a good way forward, indeed]

sean: I agree we should focus on getting as much out as we can
... without taking decisions that would be hard to undo later

jo: I don't wholy agree with this
... we need to answer some specific questions
... (e.G. validity of the various content formats)
... that are harder
... most of the other things are going to be trivial
... I think doing the hard stuff is equivalent to produce the intermediate document

sean: ok; sounds also like we have a deadline that we should keep in mind

<nacho_marin> it does not let us reach the conference

next call

jo: let's try after the BPWG call on Thursday

dom: will see if we can get room on the bridge at that time

sean: let's delay our resolutions to that time when nacho can join

dom: will send the minutes

<nacho_marin> i can't next thursday

doh

<nacho_marin> travelling back from Zaragoza

what about next monday, nacho_marin ?

<nacho_marin> ok

next monday it is, then