Re: Response data should always be in a top-level "value" property.

Simon Stewart <simon.m.stewart@gmail.com> writes:

> The problem is if there is a clash between any of the property names
> of any object ever returned by any command in the spec now or in
> future revisions and the JSON object being returned. We worried long
> and hard about this with elements, which is why we moved from
> Selenium's "ELEMENT" name to the pseudo-GUID we have now.

The main reason for the ELEMENT to element UUID key change was because
our JavaScript-to-JSON marshaling is overly simplistic when it comes to
type annotations and object serialisation, and this provided a
not-to-uncomfortable middle ground for backwards compatibility with
Selenium.

The change was not made because we worried specifically about key
conflicts in other responses or with intermediaries.  It is still the
case that if a node unintentionally overwrites a key on the response
object, that is considered to be a non-conforming implementation and a
bug.

> Also, if we ever return a map of hash from any method, there's no way
> to distinguish "returned by the driver" from "added as decoration"

The specification clearly defines what it returns from each individual
command.  What is additional is what is added as decoration.  A {value:
<real value>} indirection doesn’t change this.

> I'd like to point out again that this is a far more consistent way of
> doing things, especially since the spec is currently a mixture of
> "return a raw object", "return a raw object as a value property" and
> "return a raw primitive as a value property". As a developer, that
> lack of consistency makes me consider the wealth of interesting bugs
> and edge cases that might occur.

I don’t think there is as much inconsistency here as you make it out to
be.  If it was not for JSON imposing the slight wrinkle of the

 {value: <(string|boolean|number)>}

structure, this is no different to how we encode an element:

 {element-6066-11e4-a52e-4f735466cecf: <web element reference>}

This only means that the client needs to consume the `value` field
first, before it looks at the contents and unmarshals it into whatever
representation is idiomatic to the programming language.

Received on Wednesday, 5 October 2016 17:23:24 UTC