W3C home > Mailing lists > Public > public-browser-tools-testing@w3.org > October to December 2012

RE: Publishing a new version of the WD

From: Ross Patterson <rpatterson@parature.com>
Date: Thu, 8 Nov 2012 11:42:50 -0600
To: public-browser-tools-testing <public-browser-tools-testing@w3.org>
Message-ID: <57EC80D66F4A144B8A35812D2A30679B0A005435C5@MBX05.exg5.exghost.com>
I'm not a member of the group, so this isn't an objection.  But I have a few comments from reading the spec without the benefit of hearing it worked out, and I think that's an important perspective

* General:
	* There are at least two styles of description for protocol interactions.  The IDL style used in sec. 3.2.1 seems to me to be more rigorous than the table style in sec. 5.2.
	* I think capability descriptions might be much clearer if they were centralized into sec. 3 instead of being scattered throughout the document.  For example, the "secureSsl" capability is described in section 5.2.1 as if it were peculiar to the "get" command, but it appears to be related to any page transition that might occur, not just a transition initiated by this command.

* Sec. 2.4:
	* SessionNotCreatedException (sec. 4.1) is not defined.
	* NoSuchWindow (sec. 6.4 et al.) is not defined.
	* StaleElementReferenceException (sec. 11.2 et al.) is not defined

* Sec. 4.1:
	* Step 5 says "If the Command object had the "sessionId" field set, this may be discarded in favour of the freshly generated sessionId."  I believe "... this may be discarded ..." should be read as "... the remote end may ignore the Command's sessionId ...".  It might also be worthwhile to state that the local end MUST use the sessionId returned in the Response, even if it differs from the Command.
	* The SessionNotCreatedException descriptions speak of "the error message" and "the value", which I believe should be read as "a string returned as the value attribute of the Response".
	* Experience with other protocols (e.g., SMTP, HTTP) has shown that it can be useful for the local end to know what capabilities the remote end offers.  If the Capabilities described in step 6 were allowed to contain additional values supplied by the remote end, this would be possible.  One example of its use might be a Boolean "commandPipelining" capability, indicating the remote end's willingness to accept and queue commands while other commands are in progress, as discussed in sec. 5.3.

* Sec. 4.1.1 says "vendor code (eg: "MOZ-B2G")."  Shouldn't these be "-" + vendorPrefix + "-" + value and not upper-cased, like the extensions described in section 18.1?

* Sec 4.1.2 is missing the SessionNotCreated status code description.

* Sec. 5.1:
	* The spec should use words (e.g., "or", "equal") instead of operators derived from an unspecified language (e.g., "==", "||").  While most programmers will place ISO-C or Java interpretations upon operators, there are other interpretations as well.

* Sec. 5.2.1:
	* This section describes the secureSsl capability, which defaults to the opposite of normal browser operation (i.e., false instead of true).  Is the "sorry fact" mentioned in the NOTE truly so common that this capability should have such an unusual default?
	* Is the MAY in "... implementations MAY choose to make accessing a site with bad HTTPS ..." really justified?  If the local end has explicitly overridden the default of secureSsl=false, shouldn't this really be a MUST?  Especially if it was provided in a requiredCapabilities?

* Sec. 6.3 says "The ordering of the keys is not defined ...", which I think should be read as "The ordering of the array elements is not defined ...".

* Sec. 6.4 does not define the effect of the "fullscreenWindow" command.

* Sec. 7.2 conflates three different parameters as "name".  Shouldn't there instead be "id", "windowHandle", and "windowName" parameters with separate value sets?

* Sec. 7.3 conflates four different parameters as "id".  Shouldn't there instead be "frameNumber", "frameId", "name", and id parameters with separate value sets?

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

* Sec. 9.1's NOTE does not appear to be related to the section's content.

* Sec. 10.2 references a "getProperty" method that isn't defined anywhere in the spec.

* Sec. 12 and other later sections speak of "remote implementations".  I think this should be read as "remote ends".

* Sec. 16 and other later sections speak of "local implementations".  I think this should be read as "local ends".

* 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 :-)

Ross Patterson

-----Original Message-----
From: Simon Stewart [mailto:simon.m.stewart@gmail.com] 
Sent: Tuesday, October 30, 2012 7:22 AM
To: public-browser-tools-testing
Subject: Publishing a new version of the WD


The members of this group who were at TPAC voted on whether to publish a new working draft of the WebDriver spec. The vote was unanimously in favour. The current version can be seen at:


Before publishing that spec, are there any objections from members of this group? I shall wait until Friday before moving forward with the publishing process to allow time for objections. If any are raised, we'll attempt to deal with them before publishing.


Received on Thursday, 8 November 2012 17:43:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:48 UTC