Permalink
Browse files

Bug 24815: Remove mention of Appendix since putting it in an appendix…

… is going to be a silly since there are many IDLs in the spec
  • Loading branch information...
1 parent a8183fd commit 782451398e50a08d68808dd79543167e18a1bbb6 @AutomatedTester committed Mar 13, 2014
Showing with 26 additions and 26 deletions.
  1. +13 −13 01_introduction.html
  2. +13 −13 webdriver-spec.html
View
@@ -10,46 +10,46 @@ <h3>Intended Audience</h3>
<section>
<h3>Relationship of WebDriver API and Existing Specifications</h3>
<p>Where possible and appropriate, the WebDriver API references existing specifications. For example, the
- list of boolean attributes for elements is drawn from the
+ list of boolean attributes for elements is drawn from the
<a href="http://dev.w3.org/html5/spec/Overview.html">HTML5 specification</a>. When references are made, this
specification will link to the relevant sections.</p>
</section>
-
+
<section>
<h3>Naming the Two Sides of the API</h3>
-
+
<p>The WebDriver API can be thought of as a client/server process. However, implementation details can mean that this terminology becomes confusing. For this reason, the two sides of the API are called the "local" and the "remote" ends.</p>
<dl>
<dt><dfn id="local-end">Local</dfn></dt>
<dd>The user-facing API. <code><a href="#command-1">Command</a></code> objects are sent and <code><a href="#response">Response</a></code> objects are
consumed by the local end of the WebDriver API. It can be thought of as
being "local" to the user of the API.</dd>
-
+
<dt><dfn id="remote-end">Remote</dfn></dt>
<dd>The implementation of the user-facing API. <code><a href="#command-1">Command</a></code> objects are
consumed and <code><a href="#response">Response</a></code> objects are sent by the remote end of the WebDriver
API. The implementation of the remote end may be on a machine remote from
the user of the local end.</dd>
-
+
</dl>
-
- <p>There is no requirement that the local and remote ends be in different processes. The IDL given in this specification and summarized in Appendix XXXX SHOULD be used as the basis for any conforming local end implementation.</p>
+
+ <p>There is no requirement that the local and remote ends be in different processes. The IDLs given in this specification SHOULD be used as the basis for any conforming local end implementation.</p>
</section>
-
+
<section>
<h3>Conformance Requirements</h3>
-
+
<p>All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.</p>
-
+
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in [[!RFC2119]]. The key word "OPTIONALLY" in the normative parts of this document is to be interpreted with the same normative meaning as "MAY" and "OPTIONAL".</p>
-
+
<p>Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent.</p>
<p>The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification [[!WEBIDL]].</p>
-
+
<section>
<h3>Conformance Classes</h3>
-
+
<p>This specification describes the conformance criteria for both local (relevant to creating bindings for languages) and remote end implementations (relevant to browser vendors and server implementors). A final conformance class &mdash; <dfn id="intermediate-node">intermediate node</dfn> &mdash; is also specified. These represent those nodes situated between the local and remote ends.</p>
</section>
</section>
View
@@ -107,46 +107,46 @@ <h3>Intended Audience</h3>
<section>
<h3>Relationship of WebDriver API and Existing Specifications</h3>
<p>Where possible and appropriate, the WebDriver API references existing specifications. For example, the
- list of boolean attributes for elements is drawn from the
+ list of boolean attributes for elements is drawn from the
<a href="http://dev.w3.org/html5/spec/Overview.html">HTML5 specification</a>. When references are made, this
specification will link to the relevant sections.</p>
</section>
-
+
<section>
<h3>Naming the Two Sides of the API</h3>
-
+
<p>The WebDriver API can be thought of as a client/server process. However, implementation details can mean that this terminology becomes confusing. For this reason, the two sides of the API are called the "local" and the "remote" ends.</p>
<dl>
<dt><dfn id="local-end">Local</dfn></dt>
<dd>The user-facing API. <code><a href="#command-1">Command</a></code> objects are sent and <code><a href="#response">Response</a></code> objects are
consumed by the local end of the WebDriver API. It can be thought of as
being "local" to the user of the API.</dd>
-
+
<dt><dfn id="remote-end">Remote</dfn></dt>
<dd>The implementation of the user-facing API. <code><a href="#command-1">Command</a></code> objects are
consumed and <code><a href="#response">Response</a></code> objects are sent by the remote end of the WebDriver
API. The implementation of the remote end may be on a machine remote from
the user of the local end.</dd>
-
+
</dl>
-
- <p>There is no requirement that the local and remote ends be in different processes. The IDL given in this specification and summarized in Appendix XXXX SHOULD be used as the basis for any conforming local end implementation.</p>
+
+ <p>There is no requirement that the local and remote ends be in different processes. The IDLs given in this specification SHOULD be used as the basis for any conforming local end implementation.</p>
</section>
-
+
<section>
<h3>Conformance Requirements</h3>
-
+
<p>All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.</p>
-
+
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in [[!RFC2119]]. The key word "OPTIONALLY" in the normative parts of this document is to be interpreted with the same normative meaning as "MAY" and "OPTIONAL".</p>
-
+
<p>Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent.</p>
<p>The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification [[!WEBIDL]].</p>
-
+
<section>
<h3>Conformance Classes</h3>
-
+
<p>This specification describes the conformance criteria for both local (relevant to creating bindings for languages) and remote end implementations (relevant to browser vendors and server implementors). A final conformance class &mdash; <dfn id="intermediate-node">intermediate node</dfn> &mdash; is also specified. These represent those nodes situated between the local and remote ends.</p>
</section>
</section>

0 comments on commit 7824513

Please sign in to comment.