Re: Updates to Selectors API
On 6/14/12 10:11 AM, ext Lachlan Hunt wrote: Hi, I have updated the specification for Selectors API Level 1, which is currently in CR. Most of it was editorial in nature, to bring it in line with Selectors API Level 2, except without adding any of the new features like findAll() or or matches(). Importantly, the IDL has now been updated to comply with the most recent WebIDL specificiation. This was basically to split it up into 3 partial interfaces, just like what was previously done in v2. Some of the prose was rewritten, but none of the changes should adversely affect implementation requirements. This was mostly done by back porting the content from v2, but while ensuring that all the normative references still refer to the older, stable specs. (e.g. DOM3Core instead of using DOM4, as is used in the v2 draft.) This now makes v1 a proper subset of v2. In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). At the end of the LC review period, if no substantive changes are needed, and we already have sufficient interop data (i.e. the 2009 CR exit criteria is already met), we could skip a new CR and directly publish a PR. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. -Thanks, Art Alternatively, we could forgo any further progress with v1 and let v2 supersede it entirely, at which point I could simply rename it back to Selectors API without a version number and move on. (This is my preferred approach). http://dev.w3.org/2006/webapi/selectors-api/ http://dev.w3.org/2006/webapi/selectors-api2/
Re: Updates to Selectors API
On 2012-06-18 13:57, Arthur Barstow wrote: In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). OK. Let's get started on that process. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline (HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests. Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 tests. Opera only passes 99.2% of these and IE only passes 67.7% of these. However, these are additional tests that are not required to declare interoperability of the API, as the failures relate more to XHTML and Selectors support, rather than any particular bug with the API. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ Do I need to prepare some kind of formal testsuite report with the results for each test? However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this test suite will need to be updated with new tests, so this will likely delay PR for a little bit longer. We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. Yes please. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Updates to Selectors API
On 6/18/12 8:34 AM, ext Lachlan Hunt wrote: On 2012-06-18 13:57, Arthur Barstow wrote: In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). OK. Let's get started on that process. OK, I'll start the CfC for LC today. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline (HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests. Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 tests. Opera only passes 99.2% of these and IE only passes 67.7% of these. However, these are additional tests that are not required to declare interoperability of the API, as the failures relate more to XHTML and Selectors support, rather than any particular bug with the API. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ Do I need to prepare some kind of formal testsuite report with the results for each test? Yes, we do need to document the spec has interoperable implementations (and that is typically called the interop report). I think we have considerable flexibility on the format of the data. Here are a couple of examples: * Cam's Element Traversal http://www.w3.org/2008/webapps/ElementTraversal/index.html * Marcos' widget spec http://dev.w3.org/2006/waf/widgets/imp-report/ However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this test suite will need to be updated with new tests, so this will likely delay PR for a little bit longer. OK, that's good to know. The LC's status section should include the URI of the interop report although that document can be empty when the LC is published. (I think the status section should also mention the group expects to skip CR and go directly to PR.) We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. Yes please. Will do. -Thanks, Art
Re: Updates to Selectors API
* Lachlan Hunt wrote: At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. We can also publish v2. as a new WD. It does not seem that additional implementation experience is required to make sure no major changes are needed, so, Proposed Recommendation. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
