W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > June 2007

[minutes] London F2F meeting, day 2 (June 13)

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 13 Jun 2007 17:44:36 +0100
To: public-mobileok-checker <public-mobileok-checker@w3.org>
Message-Id: <1181753076.14035.17.camel@cumulustier>

Hi,

The minutes of our meeting today are available at:
http://www.w3.org/2007/06/13-bpwg-minutes.html

and copied as text below.

Dom

[1]W3C

      [1] http://www.w3.org/

                mobileOK ref implementation F2F, day 2

13 Jun 2007

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Jun/0001.html

   See also: [3]IRC log

      [3] http://www.w3.org/2007/06/13-bpwg-irc

Attendees

   Present
          Abel, Miguel, Ignacio, Sean, Dom, Roland, Ruadhan

   Chair
          Sean

   Scribe
          dom, ruadhan

Contents

     * [4]Topics
         1. [5]Using errors reported from other tools
         2. [6]test suites, and acceptance criteria, beta period
         3. [7]Exceptions hierarchy
         4. [8]CSS Library
         5. [9]Cacheing behavior
         6. [10]Documentation: schemas, introduction, ...
         7. [11]setting up configuration framework (e.g. for language
            setting, authentication, ...)
         8. [12]audit/estimate to completion
         9. [13]code reviews
     * [14]Summary of Action Items
     _________________________________________________________



   <dom> [15]Minutes of Day 1 (June 12)

     [15] http://www.w3.org/2007/06/12-bpwg-minutes.html

   <dom> [16]Third Party study from CTIC guys

     [16] http://lists.w3.org/Archives/Public/public-mobileok-checker/2007May/att-0087/thirdparties_study.html

   <dom> (the latest version of that document on Google Docs is dated
   June 12)

   <dom> ScribeNick: dom

Using errors reported from other tools

   Sean: I think we need to take an ad-hoc approach, do our best with
   what the tools provide, and if they don't, find our ways around

   Abel: one of the problems we identified is that most of these tools
   don't provide error codes
   ... for instance, the XHTML module in JHove only outputs a message
   and a location
   ... the image module provides a message and a bytes offset

   Sean: I think it's fine for us to parse the error messages; it's
   ugly, but probably shortest way forward
   ... would be better if they provided a better API

   Miguel: the difficulty will be to identify all the possible messages
   ... in Jhove, they are hardcoded in the source itself, not even in
   property files
   ... and of course, the messages are parametrized (e.g. to include
   the name of the element that triggered the validity error)

   Jo: if we have to review all the errors triggering code, we may as
   well fix it!

   Sean: one way to get around that is simply to include the messages
   that Jhove sends to us in the error messages we send back to the
   user

   Dom: but that's a killer in terms of I18N

   Sean: right, that's the big downside
   ... but I would still favor just doing it

   jo: I guess the question is whether perfect error reporting is part
   of our requirements or not
   ... we need to strike a balance between what we would like to
   achieve, what we need to achieve and what we can achieve in a
   reasonable amount of time

   Sean: I think we should focus on what we have to do first

   Jo: whatever we decide, we just need to make clear whatever the
   restrictions our first version will have
   ... too bad libraries don't handle this well

   Dom: I note *our* library will have exactly this same problem given
   the decision we took yesterday (non-parametrized error messages)

   Sean: I think we should proceed with the simple solution for now,
   and fix it later

   [discussions on whether we should favor a pragmatic vs esthetical
   approach]

   Dom: what you guys are doing in your tools?
   ... The checker just sends back the messages the XML validation
   library produces

   Ruadhan: same for us

   Miguel: in TAW, we had to hack around the XML validation to get
   translated messages
   ... The CSS library allowed for localization, so we didn't have the
   same problem

   Sean: let's have a better system as our goal for version 1.0, but
   move forward with the simple version now

   Miguel: if so, we should probably separate the data in the results
   ... so that it's clear that some part of the messages aren't
   produced by our library

   Sean: sounds good, indeed
   ... so we amend the results document as we discussed yesterday to
   create an additional element (e.g. "details") to include third party
   library messages

   <Zakim> dom, you wanted to propose that we have somewhere a
   reference results document so that we can now at any time the
   expected structure of the results doc

   Sean: point taken; I guess the reference would be what is in the
   test suite

   Jo: random thought of the day: should the individual test reported
   by the XSLTs have a specific version number attached?

   dom: don't think that's necessary
   ... let's wait until we would actually need it

   Jo: also, we need to look at how to report errors from the library
   ... e.g. out of memory errors

   Sean: don't think that needs to be part of the results document
   ... just throw an exception

   Jo: I think the results document should give some indication of this
   ... e.g. with a CannotTell

   Dom: I think both approach are reasonable
   ... the only question is whether exceptions get handled in or out of
   the library
   ... I think the difference is whether you consider the API to be the
   Java API or the XML API
   ... don't think we've ever made a clear decision on this

   Jo: : we should probably move on for now, but we'll need to get back
   to this

   Ruadhan: if the results document is a report, it should always
   report whether a test passed or failed, it can't be silent on it

   dom: if we can solve this with just another wrapper to catch
   exceptions, it's probably worth keeping the exceptions, as this
   gives us the best of the two worlds

   sean: doesn't seem very clean

   dom: I say, let's keep the Java API clean, and how exceptions are
   handled can be decided later on, or even by a wrapper library should
   the need arise

   sean: still not convinced, but we should move on

test suites, and acceptance criteria, beta period

   Sean: we already have a set of unit tests, which hopefully we can
   use to convince the BPWG that we do indeed implement mobileOK Basic

   Jo: one of the questions is what part of the results document
   constitute a proof that your checker is indeed a mobileOK checker

   Sean: clearly the error messages shouldn't required
   ... I guess it should be that you do report the right errors

   [discussions on protecting mobileOK checker through test suite]

   Jo: still, we need to make sure our test suite is complete

   Sean: I say we add tests as needed

   Jo: we want to keep in mind that the test suite will need to be
   versioned

Exceptions hierarchy

   Abel: currently we only have one type of Exception
   ... we could have two kinds of Exceptions
   ... to distinguish Fatal Errors (e.g. config file not found) vs
   exceptions raised in the test execution (e.g. exception raised by
   Jhove)
   ... (this relates to our earlier discussion on error reporting)

   Sean: so the question is whether we want to subclass TestException
   ... my take is someone using our code wouldn't care about what type
   of the exception
   ... I guess we could chain exceptions if we do want a hierarchy
   ... I don't oppose having a hierarchy if there is a use case for
   that

   Abel: if one test failed because of of a failure of a third party,
   what is the result?

   Sean: that's indeed the question we just discussed
   ... do we report it or not?
   ... I guess Dom and Jo argued for outputting a minimal results
   document with a CannotTell message

   dom: I think we were actually asking for a document as complete as
   possible (i.e. including the results that were indeed processed)
   ... and also some information as to why one or more of the tests
   couldn't be run

   Nacho: not sure we need a cannot tell, since it's not defined in
   mobileOK
   ... a warning should probably be enough

   Sean: I still think we should get back to that later
   ... if we keep exceptions, I think the current flat exception space
   is ok, although I'm open to expand it if use cases suggest it
   ... if we report cannottell outcomes, I don't think we should raise
   exceptions at all

CSS Library

   Nacho: I think we should decide what library to use

   Sean: so, in our choices, one was good at syntax parsing, and the
   other @@@

   Miguel: another point to consider is how to turn the CSS style sheet
   into XML if we want to process it through XSLT

   Jo: I'm not quite sure what we should do here
   ... I'm tempted to only integrate the error reports from the library
   in the moki document instead
   ... the library that turns CSS into XML has too many flaws for our
   own use
   ... and it would probably be out of our scope to develop such a
   library at this point
   ... (although it would certainly be nice to be able to do so)
   ... The best option is probably to with the SAX CSS parser, since
   it's the most likely to work for our purposes

   Sean: so we need to both validate and analyse the style sheets
   ... is one library enough or do we need two for that?

   Miguel: the SAX parser can only be used for analysis of the style
   sheet
   ... the only library I know to validate a style sheet against CSS 1
   is the W3C CSS Validator

   Dom: another option is to use the SOAP interface for the CSS
   Validator
   ... (although it prevents to use our system as an all-in-one
   package)

   Sean: I'd rather keep it in all-in-one
   ... so can we use the css validator code for our purposes?

   Miguel: yes; the only problem is that it is a bit slow

   Nacho: I think it's probably good enough for our first version of
   the checker

   Jo: this raises the point that we should have a wrapper for our
   validation code
   ... so that it's easier to swap validators if we choose to
   ... identifying a common interface around these validators would be
   a good way to identify what we want out of these validators anyway
   ... our current code is ugly

   Sean: I'm personally fine with binding directly to the library
   ... it also obscures less the code
   ... and it allows a greater use of the underlying API

   Jo: true... probably a matter of taste

   Sean: also, we're already using well-defined API (SAX, XML
   validation, etc)
   ... and if we were to change a validator, I'm not sure an abstract
   API would actually save us so much time

   Jo: I don't disagree with you
   ... it would certainly be helpful to have a common interface for
   validators, that said

   dom: note that the W3C Unicorn project has more or less defined such
   an API, if you're interested

   Jo: sounds interesting; anyway, it sounds like we're not going to
   proceed that way for the time being

   Sean: here is what I think we should do:
   ... we should remove the JXCSS thingy I had started
   ... we use the W3C CSS validator for validation
   ... and SAC for the actual test implementation

   Jo: one of the difficulties is to deal with inline CSS

   Sean: do we allow the style attribute?

   Dom: we do

   Sean: so that will need to be implemented
   ... fortunately, our tests on CSS are fairly simple (e.g. don't use
   "px")

   <scribe> ACTION: Ignacio to work with Miguel and Abel to implement
   the CSS stuff (removing JXCSS, implement validation, and use SAC for
   test implementation) [recorded in
   [17]http://www.w3.org/2007/06/13-bpwg-minutes.html#action01]

   <trackbot> Created ACTION-515 - Work with Miguel and Abel to
   implement the CSS stuff (removing JXCSS, implement validation, and
   use SAC for test implementation) [on Ignacio Marn - due 2007-06-20].

   Jo: I still think we should keep as a goal to have at some point an
   CSS-in-XML implementation in moki

   Dom: how hard would it be to use SAC to generate such a thing?
   should be relatively straightforward, isn't it?

   <scribe> ACTION: Jo to evaluate how hard it would be to produce XML
   out of CSS stylesheets using SAC [recorded in
   [18]http://www.w3.org/2007/06/13-bpwg-minutes.html#action02]

   <trackbot> Created ACTION-516 - Evaluate how hard it would be to
   produce XML out of CSS stylesheets using SAC [on Jo Rabin - due
   2007-06-20].

Cacheing behavior

   Dom: the question is what caching should our library do?

   Jo: indeed, what do we cache and under what circumstances? esp.
   given what we discovered yesterday re caching and URIs

   dom: two caching questions: keeping a list of URIs already
   downloaded in the given request vs keeping a resource that was
   downloaded for a previous analysis so that you don't have to do it
   again

   Jo: I think we shouldn't do the latter, and should do the former
   ... we also need to discuss what to do with regard to URIs given our
   discovery of yesterday

   Dom: [different cases of what browsers do in terms of
   canonicalization]

   Sean: think we should keep it simple (i.e. simple string
   comparison), and that should be pretty close to what current
   browsers do
   ... unlikely to happen very often anyway

   Dom: only thing we have to do for sure is making URIs absolute

   Ruadhan: I'm willing to take an action item to implement this

   <scribe> ACTION: Jo to annoy Ruadhan until he implements the
   in-memory caching per URIs [recorded in
   [19]http://www.w3.org/2007/06/13-bpwg-minutes.html#action04]

   <trackbot> Created ACTION-517 - Annoy Ruadhan until he implements
   the in-memory caching per URIs [on Jo Rabin - due 2007-06-20].

   "If a Mobile Web site adapts in the forest and no user agents are
   there, is it OK?" -- DanA

Documentation: schemas, introduction, ...

   <scribe> ScribeNick: ruadhan

   sean concerns what we are going to provide in end product

   jo: and schemas

   Sean: introduction, overview

   Jo: talked about yesterday
   ... don't consider ouseleves finished until we have proivided
   certain amount of documentation we need to decide what this is

   Sean: ... bug tracking?

   Dom: lets use w3c bugzilla
   ... don't like bugzilla necessarily, we could use tacker

   Roland: need docs in xslt?

   Sean: we should have comments in source also
   ... what else do we need?

   Jo: nacho mentioned developer guide

   Sean: we should take resolution not to finish until documentation is
   finished

   Jo: Problem with frameworks can be lack of documentation

   Sean: thats what developer guide will be about
   ... schema can be done later

   Jo: worth doing now

   Sean: will take user guide, de. guide,
   ... we all need to do javadoc and comments
   ... Jo will take schema and homepage

   nacho: i will take dev guide and user guide

   Jo: started homepage in adhoc way -
   ... if anyone wants to contribute, feel free, just need write access

   Sean: homepage is real nice
   ... need a mobile-friendly version

   Jo: might be ok

   Sean: anything else?

setting up configuration framework (e.g. for language setting,
authentication, ...)

   miguel: what about authentication parameters, locale...

   Sean: authentication mentioned somewhere, how do we support?

   Jo: I would like to have some minor configuration options
   ... e.g. doing our own redirection handling, but might be nice to
   use standard commons redirection

   Sean: so theres a class of development only options
   ... my concern is that mobileOK should mean one thing and be one
   thing
   ... its mobileOk or not

   Nacho: what about validating local doc that you can upload instead
   of just passing URL

   Jo: some kind of desktop integration would be nice

   sean: configure a local directory that acts as a pseudo webserver
   ... right now we already have something like this in the code
   ... test docs that have a document specifying test headers and
   starts tomcat
   ... might be nice to be able to test localhost

   Jo: more will come out but we just need a single approach

   Sean: i can name many mechanisms:
   ... config file, xml or properties, command line / env variables

   Nacho: verbosity level

   Sean: of log statemts of code?

   Nacho: granularity of results document

   Sean: the results doc should be the same all the time for
   consistency
   ... but maybe we do want a quick mode: just passes and fails

   Nacho: could be quicker if the framework is not figuring out lines
   and cols etc.
   ... was thinking about results doc to save time in processing

   Sean: how should we store this stuff

   Roland: set paramaters in web interface - quick mode or developer
   mode
   ... some config params can be set by user, there are options per
   request and per the whole thing

   Sean: config file appropriate for globale options
   ... per request, maybe a java class

   Jo: how do we make globally accessible

   Sean: within the code we could use some kind of singleton, get an
   instance of the congiuration object
   ... or configuration could live in an object within the tester

   Jo: but how to access it

   Sean: yeah, without passing it all over the place
   ... its doable...

   Jo: i don't care how its done, is this something someone can take
   on?
   ... and what is our approach to logging?

   Sean: I suggest java.util.logging

   Jo: many approaches

   Sean: preference is for java.util.logging, they all pretty much do
   the same
   ... when to log "fine" "info" "warn"
   ... recap: we've identified enought that we need a mechanism
   ... some of these features for development more than anything
   ... and what about the global config
   ... it think i can solve the global problem
   ... last question is how do we get the global options in, config
   fuile, command line options?
   ... I'm happy to do this
   ... global config in a file, and a class encapsulating the options
   ... lets talk about loggin some more later
   ... can use our judgement about when to log fine, warn, info etc.
   ... Any other requirement?

   migeul: what about example when a page includes a reference to an
   image with size 1MB
   ... do we download it, or do we set a limit?

   Sean: yeah what about files that are 10MB, or 100MB

   Jo: yes this has been on my mind
   ... the fact that we build a DOM in the first place is fundamental
   and at the heart of this issue

   Sean: one solution is to
   ... in the retrieval is if the doc > 1MB just cut if off and call a
   network error
   ... just to protect against malicious attacks

   Roland: do we limit number of resources?

   Nacho: we should have some hacking session, we try to break it

   Sean: what do you guys do?

   Dom: in checker there is a limit of number of redirects of 5
   ... checker doesn't follow link to itself
   ... Can only run it on its homepage

   ruadhan: same for ready.mobi

   Dom: i limit number of links
   ... i don't limit the size of resources

   Jo: need to both count the redirects and check they are not circular

   Sean: lets call it "safety hazards"
   ... redirects
   ... #links
   ... resource size (DOM, images)
   ... links to self
   ... stalled requests, timeouts

   Jo: what about if someone is using you as a proxy for DOS attacks

   migeul: if someone uses us as DoS, its not efficient enough as its
   not a fast process

   Sean: lets revisit this at next F2F

audit/estimate to completion

   Sean: ok, where are we?
   ... the goal is to get to something that looks like an alpha in
   early July
   ... what do we need to sort out in the next 4 weeks
   ... lets recap the actions

   Jo: css stuff needs to be done urgently

   Sean: actions 505 to 508 don't seem critical

   Jo: probably need a written document saying "yes its ok for me to
   contribute"

   Sean: action-510 (multtiple results per test is critical)
   ... action-511 is critical (research annotatsion to DOM for line and
   col)
   ... action-512 - should figure this out soon (line & col from xpath)
   ... action-513 - critical also (character encoding thingy)
   ... my intern & I will take this one
   ... action-514 needs to be done soon (implement results and encode
   in EARL if poss)

   Jo: action-516 needs to happen before 515 (both about css...)
   ... do we need ownership of portions of code

   <dom> [I just plugged tracker so that it will also watch mail sent
   to public-mobileok-checker, so that we get e.g. action items
   referenced from the Web interface]

   Sean: was hoping that these things would be done as needed
   ... e.g. if you need something in moki you would add it
   ... on target

   dom: one question is which test do i take to implement?

   <abel> [20]http://docs.google.com/Doc?id=dgh5r6zs_5cb7gz3

     [20] http://docs.google.com/Doc?id=dgh5r6zs_5cb7gz3

   Roland: i have my name on a number of tests, thats ok!
   ... i'm not so good in Java

   Sean: i'll work on non-test stuff for now

   <dom> abel, nacho, could you add me to the list of authorized
   editors for that doc (dom@w3.org)?

   Sean: alot of work here is writing test-cases...
   ... we'll continue to use google doc to coordinate this

   <dom> [I just got access through Jo, thanks!]

   Sean: goal by 1st week of july is something that kind of runs, and
   produces meanigful output

   Dom: i tried to run tester and used option to output separetly the
   results - is it just me?

   Sean: I run the unit tests, and right now, at least one fails

   Dom: command line runs, but just not doing what I expected

   Jo: i thought it was working - it was me that put that command line
   stuff in, so there's a good chance its not working!

   Sean: that concludes our list of items
   ... is there anything else we haven't talked about?

   <dom> [I just found what I was doing wrong with the command line,
   sorry for the noise]

   Jo: might be worth doing a code review

   <nacho> ACTION: Ignacio to create a preliminary version of mOK
   checker User Guide and Developer Guide documents [recorded in
   [21]http://www.w3.org/2007/06/13-bpwg-minutes.html#action05]

   <trackbot> Created ACTION-519 - Create a preliminary version of mOK
   checker User Guide and Developer Guide documents [on Ignacio Marn -
   due 2007-06-20].

code reviews

   <dom> [22]Code Source in CVS

     [22] http://dev.w3.org/cvsweb/2007/mobileok-ref/

   <dom> [23]the actual Java classes

     [23] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/

   <dom> [24]the actual Java classes

     [24] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/

   <dom> [Jo, doesn't javadoc reacts to @todo rather than TODO?]

   <dom> [25]AbstractXSLTTestImplementation.java

     [25] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/AbstractXSLTTestImplementation.java?content-type=text/x-cvsweb-markup

   <dom> [26]ThirdPartiesMessageUtils.java

     [26] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/ThirdPartiesMessageUtils.java?content-type=text/x-cvsweb-markup

   <dom> [27]ValidationMessage

     [27] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/ValidationMessage.java?content-type=text/x-cvsweb-markup

   <dom> (based originally on
   [28]http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobil
   eok/basic/XHTMLValidationErrorHandler.java from ruadhan)

     [28] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/XHTMLValidationErrorHandler.java

   <dom> [29]HTTPXHTMLResource

     [29] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/HTTPXHTMLResource.java?content-type=text/x-cvsweb-markup

   <dom> [30]HTTPResource

     [30] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/HTTPResource.java?content-type=text/x-cvsweb-markup

   <dom> [31]HTTPRedirect

     [31] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/HTTPRedirect.java?rcontent-type=text/x-cvsweb-markup

   <dom> [32]Apache commons httpclient.URI

     [32] http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/URI.html

   <dom> [33]comparison between apache commons URI and java.net URI

     [33] http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200306.mbox/%3cBAY1-DAV21K9h779ixr00007655@hotmail.com%3e

   <dom> [34]TestResults

     [34] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/TestResults.java?content-type=text/x-cvsweb-markup

   <dom> [35]Preprocessor

     [35] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/Preprocessor.java?content-type=text/x-cvsweb-markup

   <dom> ScribeNick: dom

   Jo: XSLT tests developer should pay attention to the normalization
   of HTTP headers
   ... Preprocess::addHeader uses HeaderParseMethod to take care of the
   normalization
   ... the categorization of parsing modes made in there is based on
   the RFC

   ->
   [36]http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobil
   eok/basic/xslt/ XSLT used in mobileok ref

     [36] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/xslt/

   ->
   [37]http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobil
   eok/basic/xslt/NonTextAlternativesTest.xsl?content-type=text/x-cvswe
   b-markup NonTextAlternativesTest.xsl, by Roland

     [37] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/xslt/NonTextAlternativesTest.xsl?content-type=text/x-cvsweb-markup

   ->
   [38]http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobil
   eok/basic/xslt/functions.xsl?content-type=text/x-cvsweb-markup XSLT
   Utility libraries

     [38] http://dev.w3.org/cvsweb/2007/mobileok-ref/src/org/w3c/mwi/mobileok/basic/xslt/functions.xsl?content-type=text/x-cvsweb-markup

   Roland: I try to only use match/apply-templates, no for-each
   ... makes it easier to deal with getting serveral failures
   ... for each of my test, I show the actual text of the test
   ... I have a script (moki) that allows me to run the XSLT against
   the tests in the test directory
   ... [explains some of the utility functions in functions.xsl]

   [discussions on how to present the code-snippet, on a text vs nodes
   basis, and what can actually be achieved in XSLT]

   Proposed dates for September F2F: 4th and 5th in Sophia Antipolis

   [code review from the CTIC gang]

   We note that XHTML Basic allows for URIs in its list of tokens, but
   we probably want to limit to the well-defined values

   <nacho> [i know you die to know more about bopomofo, so...
   [39]http://en.wikipedia.org/wiki/Zhuyin ]

     [39] http://en.wikipedia.org/wiki/Zhuyin

Summary of Action Items

   [NEW] ACTION: Ignacio to create a preliminary version of mOK checker
   User Guide and Developer Guide documents [recorded in
   [40]http://www.w3.org/2007/06/13-bpwg-minutes.html#action05]
   [NEW] ACTION: Ignacio to work with Miguel and Abel to implement the
   CSS stuff (removing JXCSS, implement validation, and use SAC for
   test implementation) [recorded in
   [41]http://www.w3.org/2007/06/13-bpwg-minutes.html#action01]
   [NEW] ACTION: Jo to annoy Ruadhan until he implements the in-memory
   caching per URIs [recorded in
   [42]http://www.w3.org/2007/06/13-bpwg-minutes.html#action04]
   [NEW] ACTION: Jo to evaluate how hard it would be to produce XML out
   of CSS stylesheets using SAC [recorded in
   [43]http://www.w3.org/2007/06/13-bpwg-minutes.html#action02]

   [End of minutes]
Received on Wednesday, 13 June 2007 16:44:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:03 GMT