Capabilities strategies

[shs96c]

Closes #636 amongst others.

---

This change is 

[shs96c]

There's a further step where we hook this up into the Processing Capabilities algorithms, but at least the ground work is there now.

[jgraham]

OK, done a first pass, but I don't think I got everything. I'll need to re-check the logic later.

---

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 23 unresolved discussions.

---

webdriver-spec.html, line 1979 at r2 (raw file):

coressponding

spelling

---

webdriver-spec.html, line 1980 at r2 (raw file):

 <li><p>For each <var>key</var> and <var>value</var> coressponding
  to <var>parameter</var>'s <a>own properties</a>:

Not necessarily an issue for here, but I think that this construct is confusing. The fact that you have to infer semantics from the variable names is bad. You should probably iterate over the keys corresponding to enumerable own properties and get the value inside the loop.

---

webdriver-spec.html, line 2062 at r2 (raw file):

    set the value to an empty JSON <a>Object</a>.

   <li><p>If the result of <a>validate capabilities</a> with

You could make validate capabilities return suceess or error and just <a>try</a> to validate capabilities.

---

webdriver-spec.html, line 2068 at r2 (raw file):

  </ol>

 <li><p>Let <var>desired capabilities</var> be the result of <a>getting a property</a>

I think we shouldn't call this desired capabilities because it's historically confusing.

---

webdriver-spec.html, line 2083 at r2 (raw file):

 <!-- Validate all entries first so we fail as quickly as possible -->
 <li><p>For each <var>current desired capabilities</var> coressponding

You still can't spell corresponding

---

webdriver-spec.html, line 2090 at r2 (raw file):

    <var>current desired capabilities</var>.

   <li><p>If <var>mergeable</var> is <code>true</code>, append

Huh? So we just filter out all the ones that don't validate? That seems wrong. Surely we want to return an error?

---

webdriver-spec.html, line 2122 at r2 (raw file):

  an <a>error</a> with <a>error code</a> <a>invalid argument</a>.

 <li>For each <var>key</var> and <var>value</var> coressponding

corresponding.

---

webdriver-spec.html, line 2131 at r2 (raw file):

    return <code>false</code>.

   <li><p><a>Try</a> to call <var>strategy</var> with

You can't use try here (this is a "function" with return type bool, not one that returns success or error. try isn't like exceptions because it doesn't unwind the stack more than one level; it's just implicit return-on-error).

---

webdriver-spec.html, line 2172 at r2 (raw file):

<ol>
 <li><p>Let <var>matched capabilities</var> be a JSON <a>Object</a>

This still doesn't make sense, because you can't work out what these things are until you have processed the passed in capabilities (at least in a real implementation).

---

webdriver-spec.html, line 2191 at r2 (raw file):

  </dl>

 <li><p>Add any implementation-specific capabilities as entries

This is also confusing. Real implementations mostly use parameters passed to new session as configuration options. It shouldn't be required to return every configuration option that was passed in (e.g. profile because of efficiency concerns).

---

webdriver-spec.html, line 2204 at r2 (raw file):

  to <var>capability</var>'s <a>own properties</a>:
  <ol>
   <li><p>Let <var>strategy</var> be the result of <a>finding a

I feel like this deserialization strategy stuff is mostly useless indirection. We could simply have a table of allowed names and types here. We also need to deal with the possibility of extension properties which should have a name containing a colon.

---

webdriver-spec.html, line 2285 at r2 (raw file):

     <dt>"<code>proxy</code>"
     <dd><p>If the <a>endpoint node</a> does not support the proxy

I don't think this is implementable. For starters, does not support" isn't well defined. But even if it was it's generally impossible to tell if a proxy configuration is supported without actually trying it (with PAC files it is arguably equivalent to the halting problem), which you can't do until you actually start the session.

---

webdriver-spec.html, line 2290 at r2 (raw file):

     <dt><strong>Otherwise</strong>
     <dd><p>If <var>name</var> is not recognized

What does "recognised" mean?

Can't we constrain nonstandard options to have a : in the name (c.f. moz:firefoxOptions). That produces a clear test for whether a capability is "recognised"; it is either a standard one or starts with a vendor prefix.

---

webdriver-spec.html, line 2306 at r2 (raw file):

<section>
<h3>Deserialization Strategies</h3>

This seems like a layer of indirection that isn't necessary. Why not just call the appropriate deserialization steps directly rather than having this intermediate table?

---

webdriver-spec.html, line 2321 at r2 (raw file):

 </tr>
 <tr><td>"<code>acceptInsecureCerts</code>"</td><td><a>Deserialize as a boolean</a></td></tr>
 <tr><td>"<code>browserName</code>"</td><td><a>Deserialize as a string</a></td></tr>

I don't think that this kind of simple "deserializer" is that helpful. Elsewhere we just inlined the logic.

---

webdriver-spec.html, line 2334 at r2 (raw file):

<ol>
 <li><p>If <var>value</var> is <code>null</code>

This is only for acceptInsecureCerts, right? I don't think that converting null=>false makes sense in general, but maybe does in that specific case. But we could always just remove any capabilities that are set to null in a single step, making it explicit that null is equivalent to not specifying anything.

---

webdriver-spec.html, line 2358 at r2 (raw file):

</ol>

<p>To <dfn>deserialize as identity</dfn> with

Is this used? It seems pretty useless anyway and hopefully goes away with a refactor.

---

webdriver-spec.html, line 2822 at r2 (raw file):

</table>

<p>The <a>remote end</a> steps to <dfn>deserialize as a timeout</dfn>

No need to describe these as remote end steps since they aren't the main entry point to the command.

---

webdriver-spec.html, line 2842 at r2 (raw file):

    or it is less than 0 or greater than 2<sup>64</sup> – 1,
    return <a>error</a> with <a>error code</a> <a>invalid argument</a>.
  </ol>

This algorithm doesn't return anything; it has to return success with some data. Given the way it's used it should return success with data parameters (which is pretty ugly since it's returning its argument).

---

webdriver-spec.html, line 2924 at r2 (raw file):

<ol>
 <li><p>If <var>value</var> is <code>null</code>, let <var>value</var>
  be set to "<code>normal</code>".

Quotes inside <code>

---

webdriver-spec.html, line 2933 at r2 (raw file):

  an <a>error</a> with <a>error code</a> <a>invalid argument</a>.

 <li><p>Return <var>value</var>.

You have to return success with data <var>value</var>.

---

webdriver-spec.html, line 8198 at r2 (raw file):

</table>

<p>In order to <dfn>deserialize as an unhandled prompt behavior</dfn> an

"When required to", or similar.

---

webdriver-spec.html, line 8209 at r2 (raw file):

  code</a> <a>invalid argument</a>.

 <li><p>Return <var>value</var>.

Return success with data <value</var>

---

Comments from Reviewable

[shs96c]

Review status: all files reviewed at latest revision, 23 unresolved discussions.

---

webdriver-spec.html, line 1980 at r2 (raw file):

Previously, jgraham wrote…

Not necessarily an issue for here, but I think that this construct is confusing. The fact that you have to infer semantics from the variable names is bad. You should probably iterate over the keys corresponding to enumerable own properties and get the value inside the loop.

I followed the same convention here that we have in other parts of the spec to do with iterating over own properties. I'm happy to change here, but we should also do so elsewhere too in a follow-up

---

webdriver-spec.html, line 2062 at r2 (raw file):

Previously, jgraham wrote…

You could make validate capabilities return suceess or error and just <a>try</a> to validate capabilities.

Good point :)

---

webdriver-spec.html, line 2068 at r2 (raw file):

Previously, jgraham wrote…

I think we shouldn't call this desired capabilities because it's historically confusing.

SGTM. Will change.

---

webdriver-spec.html, line 2083 at r2 (raw file):

Previously, jgraham wrote…

You still can't spell corresponding

It's weekness….

---

webdriver-spec.html, line 2090 at r2 (raw file):

Previously, jgraham wrote…

Huh? So we just filter out all the ones that don't validate? That seems wrong. Surely we want to return an error?

There are some capabilities that are valid but non-applicable (eg. "browserName -> chromedriver" being sent to geckodriver.

---

webdriver-spec.html, line 2131 at r2 (raw file):

Previously, jgraham wrote…

You can't use try here (this is a "function" with return type bool, not one that returns success or error. try isn't like exceptions because it doesn't unwind the stack more than one level; it's just implicit return-on-error).

I didn't realise that. Will reword things.

---

webdriver-spec.html, line 2191 at r2 (raw file):

Previously, jgraham wrote…

This is also confusing. Real implementations mostly use parameters passed to new session as configuration options. It shouldn't be required to return every configuration option that was passed in (e.g. profile because of efficiency concerns).

I wanted to put a reasonable place for implementations to add their own information. Otherwise, we never return anything other than the capabilities that people ask for. In the extreme case, this may mean people can't even tell the "browserName" of the remote end, which is less than ideal. Perhaps "optionally" would help?

---

webdriver-spec.html, line 2204 at r2 (raw file):

Previously, jgraham wrote…

I feel like this deserialization strategy stuff is mostly useless indirection. We could simply have a table of allowed names and types here. We also need to deal with the possibility of extension properties which should have a name containing a colon.

As a developer, this made sense to me --- basically a lookup in a map with a default return value. I could do the table thing too, but the nice thing here is we avoid duplicating information that we've already made normative in the spec.

---

webdriver-spec.html, line 2285 at r2 (raw file):

Previously, jgraham wrote…

I don't think this is implementable. For starters, does not support" isn't well defined. But even if it was it's generally impossible to tell if a proxy configuration is supported without actually trying it (with PAC files it is arguably equivalent to the halting problem), which you can't do until you actually start the session.

This is the language that was there before. I just left it alone. Things like safaridriver can probably tell up front that they're not allowed to change system proxy settings.

---

webdriver-spec.html, line 2290 at r2 (raw file):

Previously, jgraham wrote…

What does "recognised" mean?

Can't we constrain nonstandard options to have a : in the name (c.f. moz:firefoxOptions). That produces a clear test for whether a capability is "recognised"; it is either a standard one or starts with a vendor prefix.

Not unless we tighten the language in protocol extensions, which would break most implementations out there (SauceLabs and BrowserStack don't prefix their extensions, for example. Nor does selenium)

---

webdriver-spec.html, line 2306 at r2 (raw file):

Previously, jgraham wrote…

This seems like a layer of indirection that isn't necessary. Why not just call the appropriate deserialization steps directly rather than having this intermediate table?

Because there are multiple steps that follow the same deserialisation strategy (browserName and browserVersion, for example), and I hate copy-and-pasting.

---

webdriver-spec.html, line 2321 at r2 (raw file):

Previously, jgraham wrote…

I don't think that this kind of simple "deserializer" is that helpful. Elsewhere we just inlined the logic.

Boolean has the quirk that null becomes false. I can inline both.

---

webdriver-spec.html, line 2334 at r2 (raw file):

Previously, jgraham wrote…

This is only for acceptInsecureCerts, right? I don't think that converting null=>false makes sense in general, but maybe does in that specific case. But we could always just remove any capabilities that are set to null in a single step, making it explicit that null is equivalent to not specifying anything.

I like that idea. Will amend.

---

webdriver-spec.html, line 2358 at r2 (raw file):

Previously, jgraham wrote…

Is this used? It seems pretty useless anyway and hopefully goes away with a refactor.

Identity does get used. It's for intermediary nodes so that they pass capabilities through without changing them.

---

webdriver-spec.html, line 2924 at r2 (raw file):

Previously, jgraham wrote…

Quotes inside <code>

That's not how @andreastt likes things to be done, and I've adopted his preferred style. I'm happy to go either way.

---

Comments from Reviewable

[shs96c]

I need to make the amendments, but there are some questions and comments that I hope make some bits clearer. Follow up diffs tomorrow afternoon.

---

Review status: all files reviewed at latest revision, 23 unresolved discussions.

---

Comments from Reviewable

[shs96c]

Review status: all files reviewed at latest revision, 23 unresolved discussions, some commit checks failed.

---

webdriver-spec.html, line 1979 at r2 (raw file):

Previously, jgraham wrote…

coressponding

spelling

Fixed

---

webdriver-spec.html, line 2172 at r2 (raw file):

Previously, jgraham wrote…

This still doesn't make sense, because you can't work out what these things are until you have processed the passed in capabilities (at least in a real implementation).

We're building up the set of capabilities that have been matched. We'll either return them or null. As we populate this, we're checking that the values match. If they don't, null is returned.

---

webdriver-spec.html, line 2822 at r2 (raw file):

Previously, jgraham wrote…

No need to describe these as remote end steps since they aren't the main entry point to the command.

Fixed.

---

webdriver-spec.html, line 2842 at r2 (raw file):

Previously, jgraham wrote…

This algorithm doesn't return anything; it has to return success with some data. Given the way it's used it should return success with data parameters (which is pretty ugly since it's returning its argument).

Fixed.

---

webdriver-spec.html, line 2933 at r2 (raw file):

Previously, jgraham wrote…

You have to return success with data <var>value</var>.

Fixed

---

webdriver-spec.html, line 8198 at r2 (raw file):

Previously, jgraham wrote…

"When required to", or similar.

Done

---

webdriver-spec.html, line 8209 at r2 (raw file):

Previously, jgraham wrote…

Return success with data <value</var>

Done

---

Comments from Reviewable

[shs96c]

Review status: 0 of 1 files reviewed at latest revision, 23 unresolved discussions.

---

webdriver-spec.html, line 2122 at r2 (raw file):

Previously, jgraham wrote…

corresponding.

Fixed

---

Comments from Reviewable

[jgraham]

Review status: 0 of 1 files reviewed at latest revision, 16 unresolved discussions.

---

webdriver-spec.html, line 1980 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

I followed the same convention here that we have in other parts of the spec to do with iterating over own properties. I'm happy to change here, but we should also do so elsewhere too in a follow-up

#772

---

webdriver-spec.html, line 2285 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

This is the language that was there before. I just left it alone. Things like safaridriver can probably tell up front that they're not allowed to change system proxy settings.

I still think this language needs to be weakened. It seems like you're saying there are exceptional circumstances in which an implementation can know things about the allowed proxy configuration upfront. I agree in that case it should be permitted to error here, but there shouldn't be a must-level requirement to determine that.

---

webdriver-spec.html, line 2290 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

Not unless we tighten the language in protocol extensions, which would break most implementations out there (SauceLabs and BrowserStack don't prefix their extensions, for example. Nor does selenium)

I think we should have this discussion. People making up random stuff in a global namespace limits our ability to standardise going forward (we have to know about all existing extensions to avoid name clashes).

---

webdriver-spec.html, line 2924 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

That's not how @andreastt likes things to be done, and I've adopted his preferred style. I'm happy to go either way.

I… don't see what the argument for the alternative is. The code here is a string literal. Surely then the markers of it being such form part of the <code>.

---

webdriver-spec.html, line 2113 at r3 (raw file):

    argument.

   <li><p>If <var>matched capabilities</var>'s is

The "s" should be inside the <var> and there shouldn't be an apostrophe.

---

webdriver-spec.html, line 2154 at r3 (raw file):

     <dt><var>name</var> equals "<code>platformName</code>"
     <dd><p>If <var>value</var> is not a <a>string</a> return
      an <a>error</a> witha <a>error code</a> <a>invalid

"witha"

---

webdriver-spec.html, line 2185 at r3 (raw file):

    </dl>

   <li><p>If <var>deserialized</var> is

, <a>set a property</a> of <var>result</var> with name <var>name</var> and value <var>deserialized</var>

---

webdriver-spec.html, line 2209 at r3 (raw file):

    property</a> named <var>name</var> from <var>primary</var>.

   <li><a>Set a property</a> <var>name</var> to <var>value</var>

Set a property on result with name[…]

---

webdriver-spec.html, line 2227 at r3 (raw file):

    <var>primary</var>.

   <li><p>Run the substeps of the first matching condition:

Is there a use case for allowing this, rather than just rejecting cases where there's a key in common? Note that "equal" is not obviously well defined here (does the empty string equal null? Do two Objects with equal keys and values equal each other?).

---

webdriver-spec.html, line 2254 at r3 (raw file):

  <dl>
   <dt>"<code>browserName</code>"

I still think we need at least a note to indicate that in a real implementation these values may depend on other capabilities that are passed in. Designing that is the central problem in actually implementing this stuff so it is helpful if the spec acknowledges that its model is simplified.

---

webdriver-spec.html, line 2343 at r3 (raw file):

      <dd><p>If <var>value</var> is <code>true</code>
       and the <a>endpoint node</a> does not support <a>insecure TLS certificates</a>,
       return <a>error</a> with <a>error code</a> <a>invalid argument</a>.

Why are we returning an error in this case rather than null? You might have a second set of capabilities that don't require accepting insecure SSL.

---

webdriver-spec.html, line 2361 at r3 (raw file):

   </dl>

   <li><p>Create a new entry in <var>matched capabilities</var>

What does "create a new entry" mean?

---

Comments from Reviewable

[jgraham]

Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 15 unresolved discussions.

---

Comments from Reviewable

[shs96c]

Review status: all files reviewed at latest revision, 16 unresolved discussions.

---

webdriver-spec.html, line 2285 at r2 (raw file):

Previously, jgraham wrote…

I still think this language needs to be weakened. It seems like you're saying there are exceptional circumstances in which an implementation can know things about the allowed proxy configuration upfront. I agree in that case it should be permitted to error here, but there shouldn't be a must-level requirement to determine that.

I think there does need to be a check once somewhere in the end node that ensures that both "acceptInsecureCerts" and the "proxy" capabilities have been set and will be honoured.

---

webdriver-spec.html, line 2290 at r2 (raw file):

Previously, jgraham wrote…

I think we should have this discussion. People making up random stuff in a global namespace limits our ability to standardise going forward (we have to know about all existing extensions to avoid name clashes).

Realistically, people are already extending the spec with non-standard capability names that don't contain a colon, and there's nothing to say that there can't be consensus which has yet to be formalised around a capability name (the Appium, Selendroid, WebDriver Agent folks have some agreed upon capability names that are shared across multiple implementations).

I'll use "implementation-specific" as elsewhere for this text.

---

webdriver-spec.html, line 2924 at r2 (raw file):

Previously, jgraham wrote…

I… don't see what the argument for the alternative is. The code here is a string literal. Surely then the markers of it being such form part of the <code>.

@andreastt's argument is that there might be confusion about whether or not the quote marks should be part of the string or not. In his view, the quote marks indicate that the type is a string, and value within the section is the actual contents of the string.

I don't care either way, but it'd be nice if we all agreed how to handle string values in code tags. For now, I'd prefer consistency with the rest of the spec, and then a bug to tidy up afterwards.

---

webdriver-spec.html, line 2113 at r3 (raw file):

Previously, jgraham wrote…

The "s" should be inside the <var> and there shouldn't be an apostrophe.

Fixed

---

webdriver-spec.html, line 2154 at r3 (raw file):

Previously, jgraham wrote…

"witha"

Fixed

---

webdriver-spec.html, line 2185 at r3 (raw file):

Previously, jgraham wrote…

, <a>set a property</a> of <var>result</var> with name <var>name</var> and value <var>deserialized</var>

Fixed

---

webdriver-spec.html, line 2209 at r3 (raw file):

Previously, jgraham wrote…

Set a property on result with name[…]

Fixed

---

webdriver-spec.html, line 2227 at r3 (raw file):

Previously, jgraham wrote…

Is there a use case for allowing this, rather than just rejecting cases where there's a key in common? Note that "equal" is not obviously well defined here (does the empty string equal null? Do two Objects with equal keys and values equal each other?).

I can imagine local ends duplicating information here because of user inputs. We can use Object.is for comparison, which I think gets the semantics right.

---

webdriver-spec.html, line 2252 at r3 (raw file):

I still think we need at least a note to indicate that in a real implementation these values may depend on other capabilities that are passed in.

---

webdriver-spec.html, line 2254 at r3 (raw file):

Previously, jgraham wrote…

I still think we need at least a note to indicate that in a real implementation these values may depend on other capabilities that are passed in. Designing that is the central problem in actually implementing this stuff so it is helpful if the spec acknowledges that its model is simplified.

The browserName may depend on other capabilities? Does the end node not know its own name?

---

webdriver-spec.html, line 2343 at r3 (raw file):

Previously, jgraham wrote…

Why are we returning an error in this case rather than null? You might have a second set of capabilities that don't require accepting insecure SSL.

Good point.

---

webdriver-spec.html, line 2361 at r3 (raw file):

Previously, jgraham wrote…

What does "create a new entry" mean?

ahem Fixed

---

Comments from Reviewable

[jgraham]

Review status: 0 of 1 files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

---

webdriver-spec.html, line 2172 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

We're building up the set of capabilities that have been matched. We'll either return them or null. As we populate this, we're checking that the values match. If they don't, null is returned.

I think we agreed to add a note here?

---

webdriver-spec.html, line 2285 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

I think there does need to be a check once somewhere in the end node that ensures that both "acceptInsecureCerts" and the "proxy" capabilities have been set and will be honoured.

We can probably tell if that configuration is set. We can't tell if it's supported in the sense of "actually works". The language here is still wrong. I at least want an issue open to fix this.

---

webdriver-spec.html, line 2290 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

Realistically, people are already extending the spec with non-standard capability names that don't contain a colon, and there's nothing to say that there can't be consensus which has yet to be formalised around a capability name (the Appium, Selendroid, WebDriver Agent folks have some agreed upon capability names that are shared across multiple implementations).

I'll use "implementation-specific" as elsewhere for this text.

So we can't ever add a capability without auditing every extant implementation? That seems like a disaster.

---

webdriver-spec.html, line 2924 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

@andreastt's argument is that there might be confusion about whether or not the quote marks should be part of the string or not. In his view, the quote marks indicate that the type is a string, and value within the section is the actual contents of the string.

I don't care either way, but it'd be nice if we all agreed how to handle string values in code tags. For now, I'd prefer consistency with the rest of the spec, and then a bug to tidy up afterwards.

#785

---

webdriver-spec.html, line 2227 at r3 (raw file):

Previously, shs96c (Simon Stewart) wrote…

I can imagine local ends duplicating information here because of user inputs. We can use Object.is for comparison, which I think gets the semantics right.

I'm still not happy with this. Although our model is nominally js objects, I don't think that anyone is actually implementing this in js, so everyone will have to duplicate the logic from the js spec. I imagine this will create a lot of possibility for poor interop. On the other hand it's easy for a local end to do something sensible if a user adds duplicate keys to alwaysMatch and firstMatch (e.g. throw, remove from firstMatch). I also think that's clearer for users who might otherwise think they can merge complex values or something.

---

webdriver-spec.html, line 2254 at r3 (raw file):

Previously, shs96c (Simon Stewart) wrote…

The browserName may depend on other capabilities? Does the end node not know its own name?

If Microsoft had had "IEDriver" during the Edge transition then it might have occurred that a single endpoint could front a product called Edge or one called InternetExplorer depending on the path. It is easy to imagine similar rebranding "it's a new product, honest" exercises in the future.

---

webdriver-spec.html, line 2210 at r4 (raw file):

    property</a> named <var>name</var> from <var>primary</var>.

   <li><a>Set a property</a> of <var>result</var> with

s/of/on/

---

webdriver-spec.html, line 2300 at r4 (raw file):

       data <a><code>null</code></a>.

     <p class=note>There is a chance the <a>remote end</a> will need

I don't think these notes should be here, but higher up as a general note that the structure of this algorithm is based on a premise that isn't true in real implementations.

---

Comments from Reviewable

[jgraham]

Reviewed 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 9 unresolved discussions.

---

Comments from Reviewable

[shs96c]

Review status: all files reviewed at latest revision, 9 unresolved discussions.

---

webdriver-spec.html, line 2172 at r2 (raw file):

Previously, jgraham wrote…

I think we agreed to add a note here?

We did, and it's further down. :)

---

webdriver-spec.html, line 2285 at r2 (raw file):

Previously, jgraham wrote…

We can probably tell if that configuration is set. We can't tell if it's supported in the sense of "actually works". The language here is still wrong. I at least want an issue open to fix this.

Discussed on IRC. I've raised #786 to address this.

---

webdriver-spec.html, line 2290 at r2 (raw file):

Previously, jgraham wrote…

So we can't ever add a capability without auditing every extant implementation? That seems like a disaster.

We followed the CSS spec for protocol extensions, and they don't require extensions to use the vendor prefix --- https://www.w3.org/TR/CSS21/syndata.html#vendor-keywords If we're doomed, at least it'll be a party with plenty of company.

I can add a note in the protocol extensions section to say that no spec-supplied capability name will ever have a colon in it.

---

webdriver-spec.html, line 2227 at r3 (raw file):

Previously, jgraham wrote…

I'm still not happy with this. Although our model is nominally js objects, I don't think that anyone is actually implementing this in js, so everyone will have to duplicate the logic from the js spec. I imagine this will create a lot of possibility for poor interop. On the other hand it's easy for a local end to do something sensible if a user adds duplicate keys to alwaysMatch and firstMatch (e.g. throw, remove from firstMatch). I also think that's clearer for users who might otherwise think they can merge complex values or something.

I can see the argument for a lack of interoperability. I guess if the validation step only checked that deserialisation was possible we'd still have the raw JSON blob at this point. I'd be amazed if most libraries for JSON in any language didn't have some mechanism for verifying that two blobs are equivalent.

I'll remove the equality check, but I think this will cause problems for users further down the line since local end bindings are written by folks not used to reading specs.

---

webdriver-spec.html, line 2254 at r3 (raw file):

Previously, jgraham wrote…

If Microsoft had had "IEDriver" during the Edge transition then it might have occurred that a single endpoint could front a product called Edge or one called InternetExplorer depending on the path. It is easy to imagine similar rebranding "it's a new product, honest" exercises in the future.

sigh Marketing.

---

webdriver-spec.html, line 2210 at r4 (raw file):

Previously, jgraham wrote…

s/of/on/

Done

---

webdriver-spec.html, line 2300 at r4 (raw file):

Previously, jgraham wrote…

I don't think these notes should be here, but higher up as a general note that the structure of this algorithm is based on a premise that isn't true in real implementations.

I'll move this note up.

---

Comments from Reviewable

[shs96c]

Review status: 0 of 1 files reviewed at latest revision, 9 unresolved discussions.

---

webdriver-spec.html, line 2290 at r2 (raw file):

Previously, shs96c (Simon Stewart) wrote…

We followed the CSS spec for protocol extensions, and they don't require extensions to use the vendor prefix --- https://www.w3.org/TR/CSS21/syndata.html#vendor-keywords If we're doomed, at least it'll be a party with plenty of company.

I can add a note in the protocol extensions section to say that no spec-supplied capability name will ever have a colon in it.

I've now linked all of these to extension capabilities. The definition of that says that capability keys must have a ":". I think that properly addresses your concern.

---

Comments from Reviewable

[jgraham]

Reviewed 1 of 1 files at r6.
Review status: all files reviewed at latest revision, all discussions resolved.

---

webdriver-spec.html, line 2227 at r3 (raw file):

Previously, shs96c (Simon Stewart) wrote…

I can see the argument for a lack of interoperability. I guess if the validation step only checked that deserialisation was possible we'd still have the raw JSON blob at this point. I'd be amazed if most libraries for JSON in any language didn't have some mechanism for verifying that two blobs are equivalent.

I'll remove the equality check, but I think this will cause problems for users further down the line since local end bindings are written by folks not used to reading specs.

Well it seems easier to allow this in the future if there's a problem than the reverse.

---

Comments from Reviewable