Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
On Tue, Dec 3, 2013 at 10:00 PM, Travis Leithead travis.leith...@microsoft.com wrote: [...] I added this serialization step as optional, conditional on the browser storing an internalSubset. It is somewhat upsetting that in 2013 we still need to discuss why optional features and specifications that promote them are bad. I'm willing to have that debate, but I'm quite certain you already know my arguments. So maybe I can ask you to explain why you think it's a good idea. (The same goes for CDATASection obviously.) -- http://annevankesteren.nl/
Re: Objection to publishing DOM Parsing and Serialization (was Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3)
On 12/6/13 2:04 PM, ext James Robinson wrote: On Fri, Dec 6, 2013 at 5:06 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: Both Travis and I supported keeping that information in the boilerplate. The W3C Staff told us it must be removed before the LC could be published as at TR. (FYI, I filed a related Issue against the TR publication rules https://www.w3.org/community/w3process/track/issues/71. I think the public-w3process list is an appropriate place to discuss the Consortium's publication rules.) If that's the requirement from the Team to publish as TR, then I object to publishing as a TR until the requirements are fixed. If and when the publishing rules are fixed then we can consider proceeding again. (I asked for an explanation on the publication requirements.) The spec text as currently exists is actively harmful since it forks the living standard without even having a reference to it. In case you missed it, the draft LCWD does include a reference to the WHATWG spec: [[ https://dvcs.w3.org/hg/innerhtml/raw-file/tip/LCWD-DOM-Parsing-20131205.html#sotd This specification is based on the original work of the DOM Parsing and Serialization Living Specification http://domparsing.spec.whatwg.org/, though it has diverged in terms of supported features, normative requirements, and algorithm specificity. As appropriate, relevant fixes from the living standard are incorporated into this document. ]] -AB
Re: Objection to publishing DOM Parsing and Serialization (was Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3)
[ s/public-webapps-testsuite/public-webapps/ Uuugh ] On 12/7/13 10:22 AM, ext Ian Jacobs wrote: On Dec 7, 2013, at 8:42 AM, Arthur Barstow art.bars...@nokia.com wrote: [ + IanJ; Bcc public-w3process since this thread is an instance of issue-71; (see http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0824.html for the head of this thread) ] Ian, Yves, Please explain why W3C staff insist the following information (that some WebApps consider substantive) in the DOM Parsing and Serialization ED must be removed from the document before it can be published as a Technical Report (and please provide the URL of the relevant `process doc/rules` that substantiates your rationale): Hi Art, It comes as news to me that some in WebApps consider the placement of that information substantive. You have asked for published guidance for these references, which I will provide. Ian [[ https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html WHATWG Living Standard: http://domparsing.spec.whatwg.org/ ]] -Thanks, AB On 12/6/13 2:04 PM, ext James Robinson wrote: On Fri, Dec 6, 2013 at 5:06 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: Even worse is the removal of the reference to the source specification, given that you know that this is a contentious subject in this WG. Both Travis and I supported keeping that information in the boilerplate. The W3C Staff told us it must be removed before the LC could be published as at TR. (FYI, I filed a related Issue against the TR publication rules https://www.w3.org/community/w3process/track/issues/71. I think the public-w3process list is an appropriate place to discuss the Consortium's publication rules.) If that's the requirement from the Team to publish as TR, then I object to publishing as a TR until the requirements are fixed. If and when the publishing rules are fixed then we can consider proceeding again. The spec text as currently exists is actively harmful since it forks the living standard without even having a reference to it. - James -- Ian Jacobs i...@w3.org http://www.w3.org/People/Jacobs Tel: +1 718 260 9447
Objection to publishing DOM Parsing and Serialization (was Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3)
Hi Art, all, On 11/26/2013 08:43 PM, Arthur Barstow wrote: Earlier today Travis closed the last open bug for DOM Parsing and Serialization so this is a Call for Consensus (CfC) to publish a LCWD of that spec, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by December 3 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. (My apology for responding late, a single week is a rather short time for those of us who are not paid for this work.) In the first place I'd like to note that I'm unhappy with the way this specification is being edited. The way it is explicitly trying to contradict the DOM standard is uncannily similar to the way DOM 3 Events did that (which, as you may remember, led to the WG deciding against those requirements). I don't think this specification has received sufficient review to call it LC-ready, especially given that there has not been any discussion of the changes before this CfC. I also wish to strongly object to the following change: https://dvcs.w3.org/hg/innerhtml/rev/8f29e6f6eea2 which you made after the end of the CfC. I don't think it is appropriate to make such a change without requesting review. The change to the list of editors reverts bug 18935 [1], and incorrectly suggests that I am involved with this fork. Even worse is the removal of the reference to the source specification, given that you know that this is a contentious subject in this WG. I therefore object to the publication of this specification in the current form. Ms2ger [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18935
Re: Objection to publishing DOM Parsing and Serialization (was Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3)
On 12/6/13 7:40 AM, ext Ms2ger wrote: On 11/26/2013 08:43 PM, Arthur Barstow wrote: Earlier today Travis closed the last open bug for DOM Parsing and Serialization so this is a Call for Consensus (CfC) to publish a LCWD of that spec, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by December 3 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. In the first place I'd like to note that I'm unhappy with the way this specification is being edited. If you mean the technical aspects, please do file bugs or send comments to public-webapps list. The way it is explicitly trying to contradict the DOM standard is uncannily similar to the way DOM 3 Events did that (which, as you may remember, led to the WG deciding against those requirements). Please file bugs or send comments to public-webapps. I don't think this specification has received sufficient review to call it LC-ready, especially given that there has not been any discussion of the changes before this CfC. I view one of the main reasons for publishing a LCWD is to get wide review. I also wish to strongly object to the following change: https://dvcs.w3.org/hg/innerhtml/rev/8f29e6f6eea2 which you made after the end of the CfC. I don't think it is appropriate to make such a change without requesting review. The change to the list of editors reverts bug 18935 [1], and incorrectly suggests that I am involved with this fork. I'm really sorry about that. I just removed your name from the Editors list in the Draft LC https://dvcs.w3.org/hg/innerhtml/raw-file/default/LCWD-DOM-Parsing-20131205.html. Even worse is the removal of the reference to the source specification, given that you know that this is a contentious subject in this WG. Both Travis and I supported keeping that information in the boilerplate. The W3C Staff told us it must be removed before the LC could be published as at TR. (FYI, I filed a related Issue against the TR publication rules https://www.w3.org/community/w3process/track/issues/71. I think the public-w3process list is an appropriate place to discuss the Consortium's publication rules.) -ArtB I therefore object to the publication of this specification in the current form. Ms2ger [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18935
Re: Objection to publishing DOM Parsing and Serialization (was Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3)
On Fri, Dec 6, 2013 at 5:06 AM, Arthur Barstow art.bars...@nokia.comwrote: Even worse is the removal of the reference to the source specification, given that you know that this is a contentious subject in this WG. Both Travis and I supported keeping that information in the boilerplate. The W3C Staff told us it must be removed before the LC could be published as at TR. (FYI, I filed a related Issue against the TR publication rules https://www.w3.org/community/w3process/track/issues/71. I think the public-w3process list is an appropriate place to discuss the Consortium's publication rules.) If that's the requirement from the Team to publish as TR, then I object to publishing as a TR until the requirements are fixed. If and when the publishing rules are fixed then we can consider proceeding again. The spec text as currently exists is actively harmful since it forks the living standard without even having a reference to it. - James
RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
Internal Subset: The latest Firefox, Chrome and IE all support the doctype.internalSubset property in the DOM. Their behavior diverges slightly when parsing and serializing: For HTML parsing the internalSubset is ignored as specified in HTML5. This property returns null. For XHTML parsing, IE and Firefox parse the literal contents of the internal subset up until the closing angle bracket into the 'internalSubset' property. Chrome does not. For Serializing, if the browser has stored an internalSubset property, it is serialized as part of the Doctype. Since this is two out of three main browsers, I added this serialization step as optional, conditional on the browser storing an internalSubset. If browsers choose to remove their internalSubset support, then they will still be conformant to this specification. CDATASection: From what I can determine from the DOM spec (DOM4), the CDATASection object has been removed to simplify the DOM platform (Section 10.2). Which seems nice since CDATASections cannot be parsed by the HTML parser defined in HTML5. However, CDATASection (as a parser concept) is alive and well in XHTML and XML documents and as such these get parsed into CDATASection objects today on all browsers. In these cases (XHTML XML documents), I presume that the DOM spec would like browsers to store parsed CDATASection content as Text objects? Today, no browser does this. There shouldn't be any material problem that I can see for browsers to treat XHTML/XML parsed CDATASections as Text. Characters accepted without escaping in CDATASections like and would be put into a Text node literally, and then escaped out on serialization. This will make serialized text containing lots of angle brackets much larger than the original text content, but that's not a technical downside. There may be compat risk to making this change, but that's another story. Since it doesn't hurt browsers to leave it in the platform, I wonder whether there are browser implementations who want to make this change? It certainly isn't on IE's radar. I suppose I could make CDATASection serialization a historical (optional) behavior for platforms that preserve the identity of CDATASection objects in the DOM. I hate to pull it out altogether, because this is something that all platforms support interoperably today. Leaving it in the spec is not a problem because once a browser starts converting CDATASection input to Text, then the identity of the object to serialize is now Text, and the CDATASection serialization rules don't apply. It seems like there may be a separate concern with the references though. I don't currently make a reference to DOM L3 Core for CDATASection or internalSubset. Should I be? -Travis From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Wed, Nov 27, 2013 at 5:22 PM, Travis Leithead travis.leith...@microsoft.com wrote: I did end up talking about the (historical) internalSubset property of the Doctype object for serialization--since browsers will include it if they support it. Is this what you're referring to? Do all browsers include it or only some? I was referring to CDATASection. I had not noticed this doctype-related change, which also seems substantive. If you want to change the tree model relative to DOM, you really ought to argue that against the DOM specification, and not make willy-nilly changes on the serialization side. -- http://annevankesteren.nl/
Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
On Wed, Nov 27, 2013 at 5:22 PM, Travis Leithead travis.leith...@microsoft.com wrote: I did end up talking about the (historical) internalSubset property of the Doctype object for serialization--since browsers will include it if they support it. Is this what you're referring to? Do all browsers include it or only some? I was referring to CDATASection. I had not noticed this doctype-related change, which also seems substantive. If you want to change the tree model relative to DOM, you really ought to argue that against the DOM specification, and not make willy-nilly changes on the serialization side. -- http://annevankesteren.nl/
Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
On Tue, Nov 26, 2013 at 7:43 PM, Arthur Barstow art.bars...@nokia.com wrote: Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; https://dvcs.w3.org/hg/innerhtml/shortlog indicates that a number of changes have been made, including adding a dependency on DOM Level 2 Core (!), without discussion on any public forum I am aware of. -- http://annevankesteren.nl/
Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
On 11/27/13 7:17 AM, ext Anne van Kesteren wrote: On Tue, Nov 26, 2013 at 7:43 PM, Arthur Barstow art.bars...@nokia.com wrote: Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; https://dvcs.w3.org/hg/innerhtml/shortlog indicates that a number of changes have been made, including adding a dependency on DOM Level 2 Core (!), without discussion on any public forum I am aware of. WebApps has a relatively long history of giving Editors quite a bit of artistic freedom aka edit-first-review-later policy so I don't see what Travis has done as anything different. (BTW, this is codified in Webapps' Work Mode document http://www.w3.org/2008/webapps/wiki/WorkMode#Editors.) If there are any technical issues with the spec, please do raise them on the list and/or create bugs. -Thanks, ArtB
Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
On Wed, Nov 27, 2013 at 1:41 PM, Arthur Barstow art.bars...@nokia.com wrote: WebApps has a relatively long history of giving Editors quite a bit of artistic freedom aka edit-first-review-later policy so I don't see what Travis has done as anything different. (BTW, this is codified in Webapps' Work Mode document http://www.w3.org/2008/webapps/wiki/WorkMode#Editors.) If there are any technical issues with the spec, please do raise them on the list and/or create bugs. I think if you plan to reinstate features planned for removal or add dependencies on specifications thought obsolete you ought to have at least brought that up for discussion with the WG. Substantial changes to drafts should have some kind of trail, even if it's the editor filing a bug or emailing the list post commit. -- http://annevankesteren.nl/
Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
On 11/27/13 8:52 AM, ext Anne van Kesteren wrote: On Wed, Nov 27, 2013 at 1:41 PM, Arthur Barstow art.bars...@nokia.com wrote: WebApps has a relatively long history of giving Editors quite a bit of artistic freedom aka edit-first-review-later policy so I don't see what Travis has done as anything different. (BTW, this is codified in Webapps' Work Mode document http://www.w3.org/2008/webapps/wiki/WorkMode#Editors.) If there are any technical issues with the spec, please do raise them on the list and/or create bugs. I think if you plan to reinstate features planned for removal or add dependencies on specifications thought obsolete you ought to have at least brought that up for discussion with the WG. Substantial changes to drafts should have some kind of trail, even if it's the editor filing a bug or emailing the list post commit. Yes, I agree and I just updated that section accordingly. All, and Editor's in particular, please note: [[ http://www.w3.org/2008/webapps/wiki/WorkMode#Editors Editors in this Working Group have wide freedom to update (add, change, delete) text in Editor's Drafts without explicit consensus from the group. This method is referred to as Edit First and Review Later and is contrary to other WGs that follow a Review First and Edit Later editing model. Despite this policy, when a substantive change is made to a specification (for example, adding or removing a featured, adding a normative reference, etc.), Editors are expected to create a paper trail for the change such as creating a bug report and/or notifying the appropriate e-mail list. ]] -Thanks, ArtB
RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
Fair enough. By the way, I don't see the reference to DOM L2 Core in the Editor's draft (there's a reference to it in the source code, but not in the rendered HTML). I did end up talking about the (historical) internalSubset property of the Doctype object for serialization--since browsers will include it if they support it. Is this what you're referring to? -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Wednesday, November 27, 2013 6:19 AM To: Anne van Kesteren Cc: public-webapps Subject: Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3 On 11/27/13 8:52 AM, ext Anne van Kesteren wrote: On Wed, Nov 27, 2013 at 1:41 PM, Arthur Barstow art.bars...@nokia.com wrote: WebApps has a relatively long history of giving Editors quite a bit of artistic freedom aka edit-first-review-later policy so I don't see what Travis has done as anything different. (BTW, this is codified in Webapps' Work Mode document http://www.w3.org/2008/webapps/wiki/WorkMode#Editors.) If there are any technical issues with the spec, please do raise them on the list and/or create bugs. I think if you plan to reinstate features planned for removal or add dependencies on specifications thought obsolete you ought to have at least brought that up for discussion with the WG. Substantial changes to drafts should have some kind of trail, even if it's the editor filing a bug or emailing the list post commit. Yes, I agree and I just updated that section accordingly. All, and Editor's in particular, please note: [[ http://www.w3.org/2008/webapps/wiki/WorkMode#Editors Editors in this Working Group have wide freedom to update (add, change, delete) text in Editor's Drafts without explicit consensus from the group. This method is referred to as Edit First and Review Later and is contrary to other WGs that follow a Review First and Edit Later editing model. Despite this policy, when a substantive change is made to a specification (for example, adding or removing a featured, adding a normative reference, etc.), Editors are expected to create a paper trail for the change such as creating a bug report and/or notifying the appropriate e-mail list. ]] -Thanks, ArtB
RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23936 to track this LC comment :-) -Original Message- From: Travis Leithead Sent: Wednesday, November 27, 2013 9:23 AM To: 'Arthur Barstow'; Anne van Kesteren Cc: public-webapps Subject: RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3 Fair enough. By the way, I don't see the reference to DOM L2 Core in the Editor's draft (there's a reference to it in the source code, but not in the rendered HTML). I did end up talking about the (historical) internalSubset property of the Doctype object for serialization--since browsers will include it if they support it. Is this what you're referring to? -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Wednesday, November 27, 2013 6:19 AM To: Anne van Kesteren Cc: public-webapps Subject: Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3 On 11/27/13 8:52 AM, ext Anne van Kesteren wrote: On Wed, Nov 27, 2013 at 1:41 PM, Arthur Barstow art.bars...@nokia.com wrote: WebApps has a relatively long history of giving Editors quite a bit of artistic freedom aka edit-first-review-later policy so I don't see what Travis has done as anything different. (BTW, this is codified in Webapps' Work Mode document http://www.w3.org/2008/webapps/wiki/WorkMode#Editors.) If there are any technical issues with the spec, please do raise them on the list and/or create bugs. I think if you plan to reinstate features planned for removal or add dependencies on specifications thought obsolete you ought to have at least brought that up for discussion with the WG. Substantial changes to drafts should have some kind of trail, even if it's the editor filing a bug or emailing the list post commit. Yes, I agree and I just updated that section accordingly. All, and Editor's in particular, please note: [[ http://www.w3.org/2008/webapps/wiki/WorkMode#Editors Editors in this Working Group have wide freedom to update (add, change, delete) text in Editor's Drafts without explicit consensus from the group. This method is referred to as Edit First and Review Later and is contrary to other WGs that follow a Review First and Edit Later editing model. Despite this policy, when a substantive change is made to a specification (for example, adding or removing a featured, adding a normative reference, etc.), Editors are expected to create a paper trail for the change such as creating a bug report and/or notifying the appropriate e-mail list. ]] -Thanks, ArtB
CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
Earlier today Travis closed the last open bug for DOM Parsing and Serialization so this is a Call for Consensus (CfC) to publish a LCWD of that spec, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by December 3 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period for this LC is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, I18N, WAI, Privacy IG, Security IG, etc.) or external SDOs we should ask to review the LCWD, please let us know. -Thanks, AB
