- From: Robin Berjon <robin@w3.org>
- Date: Thu, 05 Jun 2014 14:50:44 +0200
- To: Glenn Adams <glenn@skynav.com>, Anne van Kesteren <annevk@annevk.nl>
- CC: Mounir Lamouri <mounir@lamouri.fr>, "www-dom@w3.org" <www-dom@w3.org>
On 05/06/2014 13:17 , Glenn Adams wrote: > Agree. However, as long as DOMError is defined in dom4, it is a > normative feature that needs to be implemented, and will be tested by > compliance testing regimes. Actually, shipping with a clearly flagged intent to deprecate IMHO means it can be left out of implementability testing. Not that this matters since it has two implementations. > In any case, it is relevant when proposing transition to PR if there are > two implementations of every defined feature. That is actually an assessment for the Director to make. For reference: """ Preferably, the Working Group SHOULD be able to demonstrate two interoperable implementations of each feature. If the Director believes that immediate Advisory Committee review is critical to the success of a technical report, the Director MAY accept to Call for Review of a Proposed Recommendation even without adequate implementation experience """ It hasn't been common practice because we collectively suffer from a slow, toxic drift towards dumb adherence to rules over thoughtful consideration of goals but I would contend that if a feature: • is clearly (enough) implementable; • is clearly (enough) useful; • and has no standing objection (particularly from an implementer) then it can ship. Worst case scenario: it gets covered by RF and can be removed in the next revision. Again, such considerations are useless for DOMError since contrary to your testing it is implemented, but it could apply to other things (e.g. document.origin). -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 5 June 2014 12:51:03 UTC