Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]
Hi All, Thanks for this analysis Xiaoqian. Based on the differences, I think moving toward a 2nd edition REC seems reasonable. Re the next publication step, it seems like the next publication should be a (4 week) wide review WD using Process-2014. Re what to do with the 1st Edition errata document, rather than put changes in that doc, I think it would be more helpful to add a link to the latest ED and make sure the ED includes a summary list of changes since REC was published. (After the 2nd edition REC is published, the link could be changed to the new REC.) Any objections to doing the above? If not, I'll start a CfC to see determine if we have broad consensus to proceed this way. -Thanks, ArtB On 5/8/15 12:58 PM, Xiaoqian Wu wrote: Thanks for bringing this up, Anssi. The diff between the REC and the latest Editor’s Draft[1] indicated at least two normative changes, so I’d like to propose a second edition of Web Storage. What do you say? Here’s my analysis for the current mutex. All your comments are welcome. * ED L174, L283 - WEBIDL Updated. The getter of the Storage interface and the key of the StorageEvent are Nullable; - The test suite has been update for these changes[2][3] . These changes are widely implemented by the browsers. - These changes are normative and should be accepted in the second edition. * ED L187 - The supported property names on a Storage object should be in the order that the keys were last added to the storage area”(added). - I wrote a test case[4] for this but the implementation doesn’t seem to follow this instruction. It’s more likely to be *in the order of keys that was defined by the user-agent*. - Giving the fact this change is non-normative, we should either ignore it or update the instruction to be *in the order of keys that was defined by the user-agent*. * ED L262 - Remove 4.3.1 (LocalStorage) Security. - The former section claimed that user agents must throw a SecurityError whenever any of the members of a Storage object originally returned by the localStorage attribute are accessed by scripts whose effective script origin is not the same as the origin of the Document of the Window object on which the localStorage attribute was accessed. - There was discussion[5] that this section wasn’t clear enough, dating back to 2012. I couldn’t find any related topics in the mailing list about why the editor removed this section after the Rec. - My test case[6] indicates none of Chrome/Firefox/Safari throws the SecurityError in that case. - This is a normative change and should be accepted in the second edition. Other changes are more editorial and can be kept in the second edition, imo. Moreover, the archives of the Issue section need to be updated in the new document because the formal archives are no longer available. A draft second edition of WebStorage[7](diff[8]) is available in GitHub. Please feel free to raise issues or PRs there. FYI, according to the 2014 process document[9], to modify a Rec, we can either go through FPWD-CR-PR-REC, or if we can prove wide review for the changes, things will be easier, i.e., CR-PR-REC. Thanks. — xiaoqian [1] https://www.diffchecker.com/npgkwj7d [2] https://github.com/w3c/web-platform-tests/pull/1784 [3] https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html [4] https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html [5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17 [6] https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror [7] https://github.com/w3c/webstorage [8] https://www.diffchecker.com/dkbtofsi [9] http://www.w3.org/2014/Process-20140801/#rec-modify On 2015-4-30, at 8:02pm, Kostiainen, Anssi anssi.kostiai...@intel.com mailto:anssi.kostiai...@intel.com wrote: Hi, On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com mailto:art.bars...@gmail.com wrote: On 4/21/15 5:39 AM, Kostiainen, Anssi wrote: Hi, Is there a plan to publish an errata to sync the Web Storage Rec [1] with the latest? I counted 8 commits cherry picked into the Editor's Draft since Rec [2]. If no errata publication is planned, I'd expect the Rec to clearly indicate its status. Re the priority of this issue, is this mostly a truth and beauty process-type request or is this issue actually creating a problem(s)? (If the later, I would appreciate it, if you would please provide some additional context.) It was creating problems. Our QA was confused which spec was the authoritative one, and wrote tests (additional ones, on top of the w-p-t tests) against the Rec spec. These tests failed since Blink is compliant with the latest, not the Rec. More context at: https://crosswalk-project.org/jira/browse/XWALK-3527 The main thing blocking the publication of errata is a commitment from someone to actually do the work. I also think Ian's
Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]
On 5/12/15 7:57 AM, cha...@yandex-team.ru wrote: I don't think we need a CfC to publish a WD, right? We should just publish it, and then open a CfC on the plan to move to 2nd edition with these changes incorporated, and asking if there are other changes we should include before we move ahead. Yes, our SOP is not to do a CfC for a `plain` WD publication but I understood a `wide review WD` as a signal the spec is feature complete and the next step is CR+. Thus in this case, it seems like a single CfC to capture that, plus the other stuff I mentioned should be sufficient. -AB
Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]
12.05.2015, 13:35, Arthur Barstow art.bars...@gmail.com: Hi All, Thanks for this analysis Xiaoqian. Based on the differences, I think moving toward a 2nd edition REC seems reasonable. Re the next publication step, it seems like the next publication should be a (4 week) wide review WD using Process-2014. Re what to do with the 1st Edition errata document, rather than put changes in that doc, I think it would be more helpful to add a link to the latest ED and make sure the ED includes a summary list of changes since REC was published. (After the 2nd edition REC is published, the link could be changed to the new REC.) Any objections to doing the above? If not, I'll start a CfC to see determine if we have broad consensus to proceed this way. I don't think we need a CfC to publish a WD, right? We should just publish it, and then open a CfC on the plan to move to 2nd edition with these changes incorporated, and asking if there are other changes we should include before we move ahead. If there are no other changes people come up with, we make a CR in a few weeks. If there are, we need to get them reviewed - if they make sense we have a WD and then a CfC on whether to take that to Rec. A couple of weeks for the CfC to give people time to check, plus a few days delay for publishing, seems a reasonable buffer for review, and we should be clear that if people need more time to check they should ask for it during the initial period of the CfC. cheers -Thanks, ArtB On 5/8/15 12:58 PM, Xiaoqian Wu wrote: Thanks for bringing this up, Anssi. The diff between the REC and the latest Editor’s Draft[1] indicated at least two normative changes, so I’d like to propose a second edition of Web Storage. What do you say? Here’s my analysis for the current mutex. All your comments are welcome. * ED L174, L283 - WEBIDL Updated. The getter of the Storage interface and the key of the StorageEvent are Nullable; - The test suite has been update for these changes[2][3] . These changes are widely implemented by the browsers. - These changes are normative and should be accepted in the second edition. * ED L187 - The supported property names on a Storage object should be in the order that the keys were last added to the storage area”(added). - I wrote a test case[4] for this but the implementation doesn’t seem to follow this instruction. It’s more likely to be *in the order of keys that was defined by the user-agent*. - Giving the fact this change is non-normative, we should either ignore it or update the instruction to be *in the order of keys that was defined by the user-agent*. * ED L262 - Remove 4.3.1 (LocalStorage) Security. - The former section claimed that user agents must throw a SecurityError whenever any of the members of a Storage object originally returned by the localStorage attribute are accessed by scripts whose effective script origin is not the same as the origin of the Document of the Window object on which the localStorage attribute was accessed. - There was discussion[5] that this section wasn’t clear enough, dating back to 2012. I couldn’t find any related topics in the mailing list about why the editor removed this section after the Rec. - My test case[6] indicates none of Chrome/Firefox/Safari throws the SecurityError in that case. - This is a normative change and should be accepted in the second edition. Other changes are more editorial and can be kept in the second edition, imo. Moreover, the archives of the Issue section need to be updated in the new document because the formal archives are no longer available. A draft second edition of WebStorage[7](diff[8]) is available in GitHub. Please feel free to raise issues or PRs there. FYI, according to the 2014 process document[9], to modify a Rec, we can either go through FPWD-CR-PR-REC, or if we can prove wide review for the changes, things will be easier, i.e., CR-PR-REC. Thanks. — xiaoqian [1] https://www.diffchecker.com/npgkwj7d [2] https://github.com/w3c/web-platform-tests/pull/1784 [3] https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html [4] https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html [5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17 [6] https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror [7] https://github.com/w3c/webstorage [8] https://www.diffchecker.com/dkbtofsi [9] http://www.w3.org/2014/Process-20140801/#rec-modify On 2015-4-30, at 8:02pm, Kostiainen, Anssi anssi.kostiai...@intel.com mailto:anssi.kostiai...@intel.com wrote: Hi, On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com mailto:art.bars...@gmail.com wrote: On 4/21/15 5:39 AM, Kostiainen, Anssi wrote: Hi, Is there a plan to publish an errata to sync the
Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]
In this case we don't know if the spec is feature complete. We just know there are things that need to be done. If they turn out to be all that needs to be done the thing is feature complete, and we ask for CR. If not, we hope to discover so now. But then, it's not a big deal either way. It just feels odd calling a draft a wide review draft, as if we didn't want that on other drafts. And fails to match what the Process requests of Working drafts which is that they all identify which bits they particularly want reviewed - changes, the whole thing, missing bits, … cheers 12.05.2015, 14:05, Arthur Barstow art.bars...@gmail.com: On 5/12/15 7:57 AM, cha...@yandex-team.ru wrote: I don't think we need a CfC to publish a WD, right? We should just publish it, and then open a CfC on the plan to move to 2nd edition with these changes incorporated, and asking if there are other changes we should include before we move ahead. Yes, our SOP is not to do a CfC for a `plain` WD publication but I understood a `wide review WD` as a signal the spec is feature complete and the next step is CR+. Thus in this case, it seems like a single CfC to capture that, plus the other stuff I mentioned should be sufficient. -AB -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]
Hi, On 08 May 2015, at 19:58, Xiaoqian Wu xiaoq...@w3.org wrote: Thanks for bringing this up, Anssi. The diff between the REC and the latest Editor’s Draft[1] indicated at least two normative changes, so I’d like to propose a second edition of Web Storage. What do you say? Here’s my analysis for the current mutex. All your comments are welcome. [...] Thanks for the analysis. We'll review. If a Second Edition would allow us to fix the /TR then that sounds good. Thanks, -Anssi
A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]
Thanks for bringing this up, Anssi. The diff between the REC and the latest Editor’s Draft[1] indicated at least two normative changes, so I’d like to propose a second edition of Web Storage. What do you say? Here’s my analysis for the current mutex. All your comments are welcome. * ED L174, L283 - WEBIDL Updated. The getter of the Storage interface and the key of the StorageEvent are Nullable; - The test suite has been update for these changes[2][3] . These changes are widely implemented by the browsers. - These changes are normative and should be accepted in the second edition. * ED L187 - The supported property names on a Storage object should be in the order that the keys were last added to the storage area”(added). - I wrote a test case[4] for this but the implementation doesn’t seem to follow this instruction. It’s more likely to be *in the order of keys that was defined by the user-agent*. - Giving the fact this change is non-normative, we should either ignore it or update the instruction to be *in the order of keys that was defined by the user-agent*. * ED L262 - Remove 4.3.1 (LocalStorage) Security. - The former section claimed that user agents must throw a SecurityError whenever any of the members of a Storage object originally returned by the localStorage attribute are accessed by scripts whose effective script origin is not the same as the origin of the Document of the Window object on which the localStorage attribute was accessed. - There was discussion[5] that this section wasn’t clear enough, dating back to 2012. I couldn’t find any related topics in the mailing list about why the editor removed this section after the Rec. - My test case[6] indicates none of Chrome/Firefox/Safari throws the SecurityError in that case. - This is a normative change and should be accepted in the second edition. Other changes are more editorial and can be kept in the second edition, imo. Moreover, the archives of the Issue section need to be updated in the new document because the formal archives are no longer available. A draft second edition of WebStorage[7](diff[8]) is available in GitHub. Please feel free to raise issues or PRs there. FYI, according to the 2014 process document[9], to modify a Rec, we can either go through FPWD-CR-PR-REC, or if we can prove wide review for the changes, things will be easier, i.e., CR-PR-REC. Thanks. — xiaoqian [1] https://www.diffchecker.com/npgkwj7d https://www.diffchecker.com/npgkwj7d [2] https://github.com/w3c/web-platform-tests/pull/1784 https://github.com/w3c/web-platform-tests/pull/1784 [3] https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html [4] https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html [5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17 https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17 [6] https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror [7] https://github.com/w3c/webstorage https://github.com/w3c/webstorage [8] https://www.diffchecker.com/dkbtofsi https://www.diffchecker.com/dkbtofsi [9] http://www.w3.org/2014/Process-20140801/#rec-modify http://www.w3.org/2014/Process-20140801/#rec-modify On 2015-4-30, at 8:02pm, Kostiainen, Anssi anssi.kostiai...@intel.com wrote: Hi, On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com wrote: On 4/21/15 5:39 AM, Kostiainen, Anssi wrote: Hi, Is there a plan to publish an errata to sync the Web Storage Rec [1] with the latest? I counted 8 commits cherry picked into the Editor's Draft since Rec [2]. If no errata publication is planned, I'd expect the Rec to clearly indicate its status. Re the priority of this issue, is this mostly a truth and beauty process-type request or is this issue actually creating a problem(s)? (If the later, I would appreciate it, if you would please provide some additional context.) It was creating problems. Our QA was confused which spec was the authoritative one, and wrote tests (additional ones, on top of the w-p-t tests) against the Rec spec. These tests failed since Blink is compliant with the latest, not the Rec. More context at: https://crosswalk-project.org/jira/browse/XWALK-3527 The main thing blocking the publication of errata is a commitment from someone to actually do the work. I also think Ian's automatic push of commits from the WHATWG version of Web Storage to [2] was stopped a long time ago so there could be additional changes to be considered, and the totality of changes could include normative changes. Did you check for these later
