- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Wed, 13 Jun 2007 21:24:59 +0100
- To: "Dominique Hazael-Massieux" <dom@w3.org>, "public-mobileok-checker" <public-mobileok-checker@w3.org>
Hi Everybody I apologise very much for leaving in such a hurry this afternoon, and especially in the middle of the CTIC presentation. (I did make it on time!) Many thanks to Sean and Google for their incredible hospitality. Special thanks to Dom for taking up the slack on scribing when everyone else had forgotten about it and apologies for my part in that collective amnesia! I hope everyone has/had a successful and uneventful journey home. Jo > -----Original Message----- > From: public-mobileok-checker-request@w3.org [mailto:public-mobileok- > checker-request@w3.org] On Behalf Of Dominique Hazael-Massieux > Sent: 13 June 2007 17:45 > To: public-mobileok-checker > Subject: [minutes] London F2F meeting, day 2 (June 13) > > > 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?c on > tent-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/ ht > tpclient/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?cont en > t-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 20:25:25 UTC