See also: IRC log
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
<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
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