Re: Publishing a new version of the WD

On Wed, Dec 26, 2012 at 5:36 PM, Ross Patterson <rpatterson@parature.com>wrote:

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

Parameter names should be case sensitive. Correcting that now. Good catch,
and thank you.


> ****
>
> **·         **4.1:****
>
> **o   **“How this warning is undefined” sounds like it’s missing some
> words.
>

Indeed. Fixed.


> ****
>
> **·         **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.
>
The first step of the algorithm has already narrowed down the set of
elements to consider to those that have a "selected" or "checked" property.
It shouldn't be possible to reach a putative step 4. I've reworked that
section now.


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

This has been handled in another part of this thread.


> Merry Christmas!
>

And a Happy New Year!

Cheers,

Simon



> 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>
> wrote:****
>
> On Fri, Dec 7, 2012 at 1:44 AM, Simon Stewart < 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>
> 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” J  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 J ****
>
>  ****
>
> * 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 J****
>
>  ****
>
> Thanks,****
>
> Ross Patterson****
>
> Parature****
>
>  ****
>
> ** **
>