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.barstow@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.barstow@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

Received on Wednesday, 27 November 2013 17:23:21 UTC