W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: Normative requirements -was focus/blur events

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 30 Mar 2006 22:04:15 +0200
To: "Ian Hickson" <ian@hixie.ch>, "Doug Schepers" <doug.schepers@vectoreal.com>
Cc: public-webapi@w3.org
Message-ID: <op.s68spdlewxe0ny@216-246-243.0506.adsl.tele2.no>

On Thu, 30 Mar 2006 08:19:40 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 30 Mar 2006, Doug Schepers wrote:
>> If you are trying to make another point besides the need for greater
>> precision going forward, please state your point more clearly.
> My point was that given the way DOM2 Events defines "DOMFocusIn" (or
> "click", or whatever), the presence or absence of that name in DOM3  
> Events
> makes no practical difference to the compliance or otherwise of XForms or
> XForms implementations.

I believe that is incorrect. Although they are not as clearly defined as  
they could be (since there is no normative RFC2119 requirement that the  
event "must" be fired...) the language of the spec is sufficiently clear  
about what is expected in general. It does not define explicitly the  
concept of focus, but then, I haven't seen a precise, useful definition -  
CSS has the former, DOM2 has something approaching the latter implied by  
way of example.

Relying on something like RFC 2119 as a requirement for formal conformance  
is a road to disaster.; It is a useful tool, but it is founded on a  
language (english) that is not formally consistent. Unless you approach it  
with a modicum of goodwill, a fair degree of intelligence, and a  
reasonable sense of how other people use it, you might as well drop it and  
use a proper mathematical valid formalism for expressing your spec. Some  
groups do this, and for some of their users it is extremely helpful. For  
other users it is just so much gobbledygook, so they typically also  
provide an english version - perhaps using semi-formal expressions like  
RFC 2119 or perhaps not.

There is a delicate balance between being formal enough to help developers  
avoid misunderstandings that lead to incompatibility, and being formal  
enough to make a spec unreadably long and stilted. That's what editors do,  
and unfortunately they are never going to satisfy everyone - if they do  
their job right they will get roughly equal accusations of both faults,  
and actual implementations will come out pretty much interoperable. While  
the accusations of failure can be useful indicators, it is the  
interoperability of implementations that is a measure of success. (Actual  
implementations, not counting those deliberately seeking to make obscure  
but possibly tenable interpretations...)



Charles McCathieNevile                     chaals@opera.com
   hablo español  -  je parle français  -  jeg lærer norsk
      Peek into the kitchen: http://snapshot.opera.com/
Received on Thursday, 30 March 2006 20:04:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC