RE: Publishing a new version of the WD

Thanks for making most of the changes I requested.  Looking at the diff, I saw a few things I felt I needed to comment on:


*         2.1:

o   The command name has changed from case-sensitive to case-insensitive.  I won't argue that that's a bad idea, but in that light I don't know whether parameter names are case-sensitive or -insensitive.  I would hope that the spec would not wind up with a "dictionary" datatype that has case-insensitive keys, but the question needs to be asked.

*         4.1:

o   "How this warning is undefined" sounds like it's missing some words.

*         10.2, 10.3:

o   The "getProperty method" appears to be just a "prose shim" to allow for discussion of DOM-object properties.  How about changing 10.2 to say:
2. If the WebElement represents an INPUT element, and if it has a "checked" property, then the property indicates whether the element is selected.
3. Otherwise, if the element has a "selected" property, it indicates whether the element is selected.

o   This calls out that the algorithm may need to end with:
4. Otherwise, the element is not selected.

And one independent question: is there a published definition of the IDL that the spec is using?  I ask because there are traditionally disagreements about how to represent boolean values, and because string case-sensitivity is a question fraught with danger outside the 7-bit ASCII world.

Merry Christmas!

Ross

From: Simon Stewart [mailto:simon.m.stewart@gmail.com]
Sent: Sunday, December 23, 2012 5:27 AM
To: Ross Patterson
Cc: public-browser-tools-testing
Subject: Re: Publishing a new version of the WD

Hi,

David and I have both spent some time working on the draft. Please take a look at tip of tree, as I've merged David and my edits together. If there are no more blockers, I say we push this once it all validates.

Cheers,

Simon
On Fri, Dec 7, 2012 at 5:17 AM, Ross Patterson <rpatterson@parature.com<mailto:rpatterson@parature.com>> wrote:
On Fri, Dec 7, 2012 at 1:44 AM, Simon Stewart < simon.m.stewart@gmail.com<mailto:simon.m.stewart@gmail.com> > wrote:

Wait, 1:44 AM?  Wow, that's commitment.

On Thu, Nov 8, 2012 at 9:42 AM, Ross Patterson <rpatterson@parature.com<mailto:rpatterson@parature.com>> wrote:
* Sec. 7.2 conflates three different parameters as "name".  Shouldn't there instead be "id", "windowHandle", and "windowName" parameters with separate value sets?

The "name" parameter could mean one of several things. That list describes the order in which that parameter should be compared with attributes of the window. The reason for doing things this way is to make the local end easier to implement: each of these types is commonly represented as a string. Given we're not even strongly typing "windowHandle" the local end (it's an opaque string) a poorly designed framework layered on top of WebDriver will cause all sorts of trouble. This way, we push the complexity into the remote end but can clearly express behaviour.

I think the spec should strive to eliminate ambiguity and to ensure clarity of intent between local and remote ends, but I see your point.

* Sec. 9 discusses the difference between a WebDriver "id" attribute and a DOM "id" attribute.  Given the huge history of ignoring the uniqueness requirement for DOM's "id", the "The IDs used to refer to different underlying DOM Elements must be unique within the session over the entire duration of the session." Should probably explicitly reject the historical illegal usage of non-unique DOM "id" values.

Isn't that expressed in "must be unique"? Or does it need to be made even clearer?

As a colleague says, "'Need' is such a strong term" :)  I would have thought the DOM id uniqueness requirement was pretty darned clear also.  But no, I think I was just venting on this particular topic :)

* Sec. 16.2 says "One of those monitors would be very cool."  Very true, but also the only instance of humor in the spec so far :-)

The second: section 1.1 has The Other Joke in it. :)

OK, +1 for more jokes then :)

Thanks,
Ross Patterson
Parature