W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [selectors-api] SVG WG Review of Selectors API

From: Erik Dahlström <ed@opera.com>
Date: Mon, 08 Dec 2008 20:12:11 +0100
To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, "Doug Schepers" <schepers@w3.org>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, www-svg <www-svg@w3.org>
Message-ID: <op.uluyalq9gqiacl@gnorps.linkoping.osa>

On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
>> == Section 6. The NodeSelector Interface
>>>> The caller must pass a valid group of selectors.
>> That's an authoring requirement, explain how that is applicable?
> It seems perfectly applicable for the spec to define how the methods
> need to be used by conforming applications.  Please explain why you
> think it is not applicable?

The spec still needs to describe what happens for the case where a user of the API doesn't adhere to this 'must' requirement (and yes, I believe it does).

However I'm not finding many examples in w3c specs of this type of requirement so far. One example I did find was from DOM 3 Core, where the createAttributeNS method makes a requirement on applications to pass the value null for the namespaceURI parameter if they wish an attribute to have no namespace. But that's a bit different in any case.

The quoted sentence from the Selectors API spec to me translates into this: "The caller must pass a valid group of selectors [in order to get a return value that is of any use. Failure to do so will result in either an exception or in some empty results.]" This should be rather obvious to the reader of the spec anyway.

IMHO the spec is trying to require something that is not enforcable anyway, and might as well not mention it, but instead just describe what happens for all possible indata.


Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 8 December 2008 19:15:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:49 UTC