chore: use TD 1.1 REC instead of custom reference

JKRhb · JKRhb · commit 823f60ae64be · 2024-05-15T09:55:22.000+02:00
diff --git a/index.html b/index.html
@@ -53,14 +53,8 @@
         ],
         xref: ["web-platform", "HTML", "INFRA", "URL", "WEBIDL", "DOM", "FETCH",
                "ecmascript", "streams",
-               "wot-architecture11", "wot-thing-description", "wot-binding-templates"],
+               "wot-architecture11", "wot-thing-description11", "wot-binding-templates"],
         localBiblio: {
-          "WOT-TD" : {
-            href:"https://www.w3.org/TR/2023/CR-wot-thing-description11-20230119/",
-            title: "Web of Things (WoT) Thing Description 1.1",
-            publisher: "W3C",
-            date: "19 January 2023"
-          },
           "WOT-DISCOVERY" : {
             href:"https://www.w3.org/TR/2023/CR-wot-discovery-20230119/",
             title: "Web of Things (WoT) Discovery",
@@ -177,7 +171,7 @@
       This specification describes an application programming interface (API) representing the <a>WoT Interface</a> that allows scripts to discover, operate <a>Thing</a>s and to expose locally defined <a>Thing</a>s characterized by <a> WoT Interactions</a> specified by a script.
     </p>
     <p>
-      The APIs defined in this document deliberately follow the [[[WOT-TD]]] specification closely. It is possible to implement more abstract APIs on top of them, or implementing directly the WoT network facing interface (i.e. the <a>WoT Interface</a>).
+      The APIs defined in this document deliberately follow the [[[wot-thing-description11]]] specification closely. It is possible to implement more abstract APIs on top of them, or implementing directly the WoT network facing interface (i.e. the <a>WoT Interface</a>).
     </p>
     <p class="ednote">
       This specification is implemented at least by the <a href="https://www.thingweb.io/">Eclipse Thingweb</a>
@@ -380,13 +374,13 @@
   <section> <h2>Terminology and conventions</h2>
     <p>
       The generic WoT terminology is defined in [[!wot-architecture11]]: <dfn data-lt="Things">Thing</dfn>, <dfn data-lt="Thing Descriptions">Thing Description</dfn> (in short <dfn>TD</dfn>), <dfn>Partial TD</dfn>, <dfn>Web of Things</dfn> (in short <b><i>WoT</i></b>),  <dfn>WoT Interface</dfn>, <dfn>Protocol Bindings</dfn>, <dfn>WoT Runtime</dfn>, <dfn data-lt="consume|consume a TD|consuming a TD">Consuming a Thing Description</dfn>, <dfn>TD Directory</dfn>, <dfn data-lt="Properties">Property</dfn>, <dfn data-lt="Actions">Action</dfn>, <dfn data-lt="Events|WoT-Event">Event</dfn>,
-      <a data-cite="WOT-TD#dataschema">
-        <dfn>DataSchema</dfn></a>, <a data-cite="WOT-TD#form"><dfn data-lt="Forms">Form</dfn></a>,
-        <a data-cite="WOT-TD#securityscheme"><dfn>SecurityScheme</dfn></a>, <a data-cite="WOT-TD#nosecurityscheme"><dfn>NoSecurityScheme</dfn></a> etc.
+      <a data-cite="wot-thing-description11#dataschema">
+        <dfn>DataSchema</dfn></a>, <a data-cite="wot-thing-description11#form"><dfn data-lt="Forms">Form</dfn></a>,
+        <a data-cite="wot-thing-description11#securityscheme"><dfn>SecurityScheme</dfn></a>, <a data-cite="wot-thing-description11#nosecurityscheme"><dfn>NoSecurityScheme</dfn></a> etc.
     </p>
     <p>
       <dfn data-plurals="WoT Interactions">WoT Interaction</dfn> is a synonym for <a data-cite="wot-architecture11#dfn-interaction-affordance"><dfn>Interaction Affordance</dfn></a>.
-      An <a>Interaction Affordance</a> (or shortly, affordance) is the term used in [[!WOT-TD]]
+      An <a>Interaction Affordance</a> (or shortly, affordance) is the term used in [[!wot-thing-description11]]
       when referring to <a>Thing</a> capabilities, as explained in
       <a href="https://github.com/w3c/wot-thing-description/issues/282">TD issue 282</a>.
       However, this term is not well understood outside the <a>TD</a> semantic context.
@@ -479,9 +473,9 @@ <h2>The <dfn>ThingDescription</dfn> type</h2>
 
     <p>
       Represents a <a>Thing Description</a> (<a>TD</a>) as
-      <a data-cite="WOT-TD#">defined</a> in
-      [[!WOT-TD]]. It is expected to be
-      a <a data-cite="infra#parse-json-bytes-to-a-javascript-value">parsed JSON object</a> that is validated using <a data-cite="WOT-TD#json-schema-for-validation">JSON Schema validation</a>.
+      <a data-cite="wot-thing-description11#">defined</a> in
+      [[!wot-thing-description11]]. It is expected to be
+      a <a data-cite="infra#parse-json-bytes-to-a-javascript-value">parsed JSON object</a> that is validated using <a data-cite="wot-thing-description11#json-schema-for-validation">JSON Schema validation</a>.
     </p>
     <section> <h3> Requesting a Thing Description</h3>
       <p>
@@ -503,31 +497,31 @@ <h2>The <dfn>ThingDescription</dfn> type</h2>
 
     <section> <h3>Expanding a Thing Description</h3>
       <p>
-        Note that the [[[WOT-TD]]] specification allows using a shortened <a>Thing Description</a>
-        by the means of <a data-cite="WOT-TD#sec-default-values">defaults</a> and requiring clients to expand them with default values specified in the
-        [[[WOT-TD]]] specification for the properties that are not explicitly defined in a given
+        Note that the [[[wot-thing-description11]]] specification allows using a shortened <a>Thing Description</a>
+        by the means of <a data-cite="wot-thing-description11#sec-default-values">defaults</a> and requiring clients to expand them with default values specified in the
+        [[[wot-thing-description11]]] specification for the properties that are not explicitly defined in a given
         <a>TD</a>.
       </p>
       <div>
         To <dfn>expand a TD</dfn> given |td:ThingDescription|, run the following steps:
         <ol>
           <li>
-            For each item in the <a data-cite="WOT-TD#sec-default-values">TD default values</a> table from [[!WOT-TD]], if the term is not defined in |td|, add the term definition with the default value specified in [[!WOT-TD]].
+            For each item in the <a data-cite="wot-thing-description11#sec-default-values">TD default values</a> table from [[!wot-thing-description11]], if the term is not defined in |td|, add the term definition with the default value specified in [[!wot-thing-description11]].
           </li>
         </ol>
       </div>
     </section>
 
     <section> <h3>Validating a Thing Description</h3>
       <p>
-        The [[!WOT-TD]] specification defines how a <a>TD</a> should be validated.
+        The [[!wot-thing-description11]] specification defines how a <a>TD</a> should be validated.
         Therefore, this API expects the {{ThingDescription}} objects be validated before used as parameters. This specification defines a basic <a>TD</a> validation as follows.
       </p>
       <div>
         To <dfn>validate a TD</dfn> given |td:ThingDescription|, run the following steps:
         <ol>
           <li>
-            If <a data-cite="WOT-TD#json-schema-for-validation">JSON Schema
+            If <a data-cite="wot-thing-description11#json-schema-for-validation">JSON Schema
             validation</a> fails on |td|, [= exception/throw =] a {{"TypeError"}} and stop.
           </li>
         </ol>
@@ -568,7 +562,7 @@ <h2>The <dfn>WOT</dfn> namespace</dfn></h2>
           Let |thing:ConsumedThing| be a new {{ConsumedThing}} object constructed from |td|.
         </li>
         <li>
-          Set up the <a>WoT Interactions</a> based on introspecting <a>td</a> as explained in [[!WOT-TD]] and [[!WOT-PROTOCOL-BINDINGS]]. Make a request to the underlying platform to initialize the <a>Protocol Bindings</a>.
+          Set up the <a>WoT Interactions</a> based on introspecting <a>td</a> as explained in [[!wot-thing-description11]] and [[!WOT-PROTOCOL-BINDINGS]]. Make a request to the underlying platform to initialize the <a>Protocol Bindings</a>.
           <p class="ednote">
             Implementations encapsulate the complexity of how to use the
             <a>Protocol Bindings</a> for implementing <a>WoT interactions</a>.
@@ -650,7 +644,7 @@ <h3>Expand an ExposedThingInit</h3>
           </ol>
         </li>
         <li>Search for missing required properties in |td| accordingly to
-          <a data-cite="WOT-TD#json-schema-for-validation">TD JSON
+          <a data-cite="wot-thing-description11#json-schema-for-validation">TD JSON
             Schema</a>.
           <p class="ednote">The editors find this step vague. It will be improved or removed in the next iteration. </p>
         </li>
@@ -681,7 +675,7 @@ <h3>Validating an ExposedThingInit</h3>
       To <dfn>validate an ExposedThingInit</dfn> given |init:ExposedThingInit|, run the following steps:
       <ol  class="algorithm">
         <li>
-          Parse <a data-cite="WOT-TD#json-schema-for-validation">TD JSON
+          Parse <a data-cite="wot-thing-description11#json-schema-for-validation">TD JSON
             Schema</a>
           and load it in object called |exposedThingInitSchema:object|
         </li>
@@ -861,10 +855,10 @@ <h3>Validating an ExposedThingInit</h3>
 
   <section data-cite="webidl"> <h2>Handling interaction data</h2>
   <p>
-    As specified in the [[[WOT-TD]]] specification, <a>WoT interactions</a> extend <a>DataSchema</a>
+    As specified in the [[[wot-thing-description11]]] specification, <a>WoT interactions</a> extend <a>DataSchema</a>
     and include a number of possible <a>Form</a>s, out of which one is selected
     for the interaction. The
-    <a data-cite="WOT-TD#form">
+    <a data-cite="wot-thing-description11#form">
     Form</a> contains a `contentType` to describe the data.
     For certain content types, a <a>DataSchema</a> is defined, based on
     <a>JSON Schema</a>, making possible to represent these contents as
@@ -883,7 +877,7 @@ <h2>The <dfn>InteractionInput</dfn> type</h2>
     </p>
     <p>
       <dfn>DataSchemaValue</dfn> is an
-      <a data-cite="ECMASCRIPT#sec-ecmascript-data-types-and-values">ECMAScript value</a> that is accepted for <a>DataSchema</a> defined in [[WoT-TD]].
+      <a data-cite="ECMASCRIPT#sec-ecmascript-data-types-and-values">ECMAScript value</a> that is accepted for <a>DataSchema</a> defined in [[wot-thing-description11]].
 	  The possible values MUST be of type <a data-cite="ECMASCRIPT#sec-ecmascript-language-types-null-type">null</a>, <a data-cite="ECMASCRIPT#sec-ecmascript-language-types-boolean-type">boolean</a>, <a data-cite="ECMASCRIPT#sec-ecmascript-language-types-number-type">number</a>, <a data-cite="ECMASCRIPT#sec-ecmascript-language-types-string-type">string</a>, <a data-cite="ECMASCRIPT#sec-array-objects">array</a>, or <a data-cite="ECMASCRIPT#sec-object-type">object</a>.
     </p>
     <p>
@@ -949,7 +943,7 @@ <h2>The <dfn>InteractionOutput</dfn> interface</h2>
     </p>
     <p>
       The <dfn>schema</dfn> attribute represents the <a>DataSchema</a>
-      (defined in [[WoT-TD]]) of the payload as a {{JSON}} object, initially `null`.
+      (defined in [[wot-thing-description11]]) of the payload as a {{JSON}} object, initially `null`.
     </p>
     <p>
       The <dfn data-lt="value">[[\value]]</dfn> internal slot represents the parsed value of
@@ -2169,10 +2163,10 @@ <h3>
         The <dfn>uriVariables</dfn> property if defined, represents the URI
         template variables to be used with the WoT Interaction that are represented
         as <a data-cite="infra#parse-json-bytes-to-a-javascript-value">
-        parsed JSON objects</a> defined in [[!WOT-TD]].
+        parsed JSON objects</a> defined in [[!wot-thing-description11]].
       </p>
       <p class="ednote">
-        The support for URI variables comes from the need, exposed by the [[[WOT-TD]]] specification, to be able to describe
+        The support for URI variables comes from the need, exposed by the [[[wot-thing-description11]]] specification, to be able to describe
         existing RESTful endpoints that use them. However, it should be possible to write a Thing Description that would use
         <a>Action</a>s for representing this kind of interactions and model the URI variables as action parameters. In that case,
         implementations can serialize the parameters as URI variables, and therefore, the |options| parameter could be
@@ -3600,7 +3594,7 @@ <h3>The <dfn>EventSubscriptionHandler</dfn> callback</h3>
           </li>
           <li>
             Set up the <a>WoT Interactions</a> based on introspecting {{ExposedThing/[[td]]}}
-            as explained in [[!WOT-TD]] and [[!WOT-PROTOCOL-BINDINGS]].
+            as explained in [[!wot-thing-description11]] and [[!WOT-PROTOCOL-BINDINGS]].
             Make a request to the underlying platform to initialize the
             <a>Protocol Bindings</a> and then start serving external requests
             for <a>WoT Interactions</a> (read, write and observe <a>Properties</a>,
@@ -4261,7 +4255,7 @@ <h2>API design rationale</h2>
           lock.open('withThisKey');
         </pre>
       </section>
-      <section> <h3>This API, aligned with the [[[WOT-TD]]] specification</h3>
+      <section> <h3>This API, aligned with the [[[wot-thing-description11]]] specification</h3>
         <p>
           Since the direct mapping of <a>Thing</a>s to software objects have had
           some challenges, this specification takes another approach that
@@ -4286,11 +4280,11 @@ <h2>API design rationale</h2>
       </section>
       <p>
         In conclusion, the WoT WG decided to explore the third option that
-        closely follows the [[[WOT-TD]]] specification. Based on this, a simple
+        closely follows the [[[wot-thing-description11]]] specification. Based on this, a simple
         API can also be implemented.
         Since Scripting is an optional module in WoT, this leaves room for
         applications that only use the <a>WoT network interface</a>.
-        Therefore all three approaches above are supported by the [[[WOT-TD]]] specification.
+        Therefore all three approaches above are supported by the [[[wot-thing-description11]]] specification.
       </p>
       <p>
         Moreover, the <a>WoT network interface</a> can be implemented in many languages
@@ -4313,7 +4307,7 @@ <h4>Requesting and validating a TD</h4>
         HTTP client library, which offer already standardized options on
         specifying fetch details.
         In these cases, the user is required to perform validation manually as
-        described by the [[[WOT-TD]]] specification.
+        described by the [[[wot-thing-description11]]] specification.
       </p>
       <p class="ednote" title="Extending the `requestThingDescription()` method">
         In the future, `requestThingDescription()` might be extended with an
@@ -4353,7 +4347,7 @@ <h4>Requesting and validating a TD</h4>
     </section>
     <section> <h4>Polymorphic functions</h4>
       <p>
-        The reason to use function names like <code>readProperty()</code>, <code>readMultipleProperties()</code> etc. instead of a generic polymorphic <code>read()</code> function is that the current names map exactly to the <code>"op"</code> vocabulary from the <a data-cite="WOT-TD#form">Form</a> definition in the [[[WOT-TD]]] specification.
+        The reason to use function names like <code>readProperty()</code>, <code>readMultipleProperties()</code> etc. instead of a generic polymorphic <code>read()</code> function is that the current names map exactly to the <code>"op"</code> vocabulary from the <a data-cite="wot-thing-description11#form">Form</a> definition in the [[[wot-thing-description11]]] specification.
       </p>
     </section>
   </section>
