You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A W3C Registry Track document that contains the WoT Bindings Registry Table, its requirements and possibly other information. See <ahref="https://www.w3.org/policies/process/#registry">registry</a> for more information on the definition.
155
+
A W3C Registry Track document that contains the <a>WoT Bindings Registry Table</a>, its requirements and possibly other information. See <ahref="https://www.w3.org/policies/process/#registry">registry</a> for more information on the definition.
<dfnid="dfn-execution-binding-instance">Execution of a Binding Instance</dfn>
177
177
</dt>
178
178
<dd>
179
-
The request on the wire that is sent after parsing a TD's binding instance.
179
+
The request on the wire that is sent after parsing a TD's <a>binding instance</a>.
180
180
</dd>
181
181
<dt>
182
182
<dfnid="dfn-wot-x-binding-summary">WoT X Binding Summary</dfn>
@@ -188,13 +188,13 @@ <h2>Terminology</h2>
188
188
<dfnid="dfn-wot-x-binding-json-schema">WoT X Binding JSON Schema</dfn>
189
189
</dt>
190
190
<dd>
191
-
A JSON Schema that allows validating the elements added by the WoT X Binding (registry entry). This is a supporting document for a binding entry.
191
+
A JSON Schema that allows validating the elements added by the <a>WoT X Binding</a> (registry entry). This is a supporting document for a binding entry.
192
192
</dd>
193
193
<dt>
194
194
<dfnid="dfn-wot-x-binding-json-ld-context">WoT X Binding JSON-LD Context</dfn>
195
195
</dt>
196
196
<dd>
197
-
A machine-readable JSON-LD document that defines all the terms to be used in a binding instance, which allows the terms to be dereferenced correctly by a JSON-LD parser. This is a supporting document for a binding entry.
197
+
A machine-readable JSON-LD document that defines all the terms to be used in a <a>binding instance</a>, which allows the terms to be dereferenced correctly by a JSON-LD parser. This is a supporting document for a binding entry.
198
198
</dd>
199
199
<dt>
200
200
<dfnid="dfn-x-vocabulary-rdf">X Vocabulary in RDF</dfn>
A human-readable version of the vocabulary defined at X Vocabulary in RDF. This is a supporting document for a binding entry.
209
+
A human-readable version of the vocabulary defined at <a>X Vocabulary in RDF</a>. This is a supporting document for a binding entry.
210
210
</dd>
211
211
<dt>
212
212
<dfnid="dfn-custodian">Custodian</dfn>
@@ -290,7 +290,7 @@ <h2>Intro Section of the Document</h2>
290
290
<sectionid="content-registry-definition">
291
291
<h2>Content of Registry Definition</h2>
292
292
293
-
<p>A set of rules extending the <ahref="https://www.w3.org/2023/Process-20230612/#reg-def">Registry Definitions from the W3C Process Document</a> can be found below and is structured as follows.</p>
293
+
<p>A <ahref="#dfn-wot-bindings-registry-definition">set of rules</a> extending the <ahref="https://www.w3.org/2023/Process-20230612/#reg-def">Registry Definitions from the W3C Process Document</a> can be found below and is structured as follows.</p>
<li>We work with issues only. The information for the entry format is submitted as a list. This way, non-W3C members can submit a binding. Reviews from the custodian happen on the issue. The submitter is expected to answer until the custodian makes a PR to add the binding to the registry or change its status.</li>
417
-
<li>A purpose built GitHub project for tracking submissions is used. When a submission comes in form an issue, it is automatically added to column "Binding Submitted". When the custodian and reviewers start looking at it, it goes to the "Under Review" column. If the review is in favor, the custodian makes the PR to add it to the registry and the issue goes to column "Accepted". If the review is not in favor, it goes to the column "Rejected". All these changes are reflected as comments in the original issue.</li>
417
+
<li>A purpose built GitHub project for tracking submissions is used. When a submission comes in form an issue, it is automatically added to column "Binding Submitted". When the <a>custodian</a> and <a>reviewers</a> start looking at it, it goes to the "Under Review" column. If the review is in favor, the custodian makes the PR to add it to the registry and the issue goes to column "Accepted". If the review is not in favor, it goes to the column "Rejected". All these changes are reflected as comments in the original issue.</li>
418
418
<li><spanclass="rfc2119-assertion" id="life-subm-mark-conflict">If a new entry conflicts with another entry, the reviewer MUST mark the new submission accordingly.</span><spanclass="rfc2119-assertion" id="life-subm-conflict-deprecation-rejection">As two bindings that do the same are not allowed, either the old one MUST be deprecated or the new one MUST be rejected.</span> See also point 13 under "Requirements on the Submitted Document".</li>
419
419
</ul>
420
420
</section>
@@ -461,7 +461,7 @@ <h2>Ownership</h2>
461
461
462
462
<sectionid="own-cust">
463
463
<h3>Custodian</h3>
464
-
<p>If the WoT WG no longer exists, the W3C Team or its delegated entity becomes the custodian. For example, a dedicated W3C community group can be created to maintain the registry. This way, the registry can be maintained for a long period.</p>
464
+
<p>If the WoT WG no longer exists, the W3C Team or its delegated entity becomes the <a>Custodian</a>. For example, a dedicated W3C community group can be created to maintain the registry. This way, the registry can be maintained for a long period.</p>
465
465
</section>
466
466
467
467
<sectionid="own-rev">
@@ -537,7 +537,7 @@ <h3>Reviewer Access</h3>
537
537
538
538
<sectionid="req-summ">
539
539
<h3>Summary Document</h3>
540
-
<p><spanclass="rfc2119-assertion" id="submission-requirements-summary-document">The submitter MUST fill in the GitHub form provided by the custodian to generate the summary document, which is hosted by the custodian together with the registry.</span> This form contains the following:</p>
540
+
<p><spanclass="rfc2119-assertion" id="submission-requirements-summary-document">The submitter MUST fill in the GitHub form provided by the custodian to generate the <ahref="#dfn-wot-x-binding-summary">summary document</a>, which is hosted by the custodian together with the registry.</span> This form contains the following:</p>
541
541
<ul>
542
542
<li><spanclass="rfc2119-assertion" id="submission-requirements-summary-document-abstract">Abstract - It MUST contain an abstract with the following information</span>:<ul>
543
543
<li>What is the content of the binding about, e.g., what is this protocol?</li>
@@ -568,14 +568,14 @@ <h3>Transition</h3>
568
568
<p>Transition from <code>Initial</code> to <code>Current</code></p>
569
569
<ul>
570
570
<li><spanclass="rfc2119-assertion" id="submission-requirements-transition-submission">Starting from the initial submission, each binding MUST demonstrate a certain level of concrete development maturity.</span> This process involves real-world testing, which can take place in Plugfests, independent testing events, or even informal collaboration between developers. These testing events do not have to be organized by W3C and can be conducted remotely, including over VPN. The goal is to demonstrate that the binding correctly maps protocol operations and is well understood by at least two parties.</li>
571
-
<li><spanclass="rfc2119-assertion" id="submission-requirements-transition-validated">At each testing event, every operation defined in the binding MUST be validated automatically (e.g., scripts, test suites, etc.).</span><spanclass="rfc2119-assertion" id="submission-requirements-transition-dedicated-document">The results SHOULD be published in a dedicated document (README, or other human-readable documents) called <em>Test Report</em>.</span></li>
571
+
<li><spanclass="rfc2119-assertion" id="submission-requirements-transition-validated">At each testing event, <ahref="#dfn-execution-binding-instance">every operation defined in the binding MUST be validated</a> automatically (e.g., scripts, test suites, etc.).</span><spanclass="rfc2119-assertion" id="submission-requirements-transition-dedicated-document">The results SHOULD be published in a dedicated document (README, or other human-readable documents) called <em>Test Report</em>.</span></li>
572
572
<li><em>Test Report</em><ul>
573
573
<li><spanclass="rfc2119-assertion" id="submission-requirements-test-report-information">A <em>Test Report</em> MUST contain information on the testing environment.</span></li>
574
574
<li><spanclass="rfc2119-assertion" id="submission-requirements-test-report-logical-process">A <em>Test Report</em> MUST provide an example of the logical process (not necessarily code) about how a TD can be processed to establish a communication between consumer and exposer.</span></li>
575
575
<li><spanclass="rfc2119-assertion" id="submission-requirements-test-report-scenario">A <em>Test Report</em> MUST contain information about the scenario that was tested, e.g. controlling the room temperature by measuring temperature and adjusting the heater.</span></li>
576
576
<li><spanclass="rfc2119-assertion" id="submission-requirements-test-report-implementation-experience">A <em>Test Report</em> MUST explain where discussions on implementation experience should be collected.</span></li>
577
577
<li><spanclass="rfc2119-assertion" id="submission-requirements-test-report-history">A <em>Test Report</em> SHOULD provide the history of all the past testing events (or explain how to retrieve the history of the results gathered during those events).</span></li>
578
-
<li><spanclass="rfc2119-assertion" id="submission-requirements-test-report-reference">A <em>Test Report</em>SHOULD contain a reference to the implementations of Consumers or Exposers.</span></li>
578
+
<li><spanclass="rfc2119-assertion" id="submission-requirements-test-report-reference">A <em>Test Report</em>SHOULD contain a reference to the <ahref="#dfn-wot-x-binding-implementation">implementations of Consumers or Exposers</a>.</span></li>
579
579
</ul>
580
580
</li>
581
581
<li><spanclass="rfc2119-assertion" id="submission-requirements-test-report-current-state">For the binding to transition to the "Current" state, a <em>Test Report</em> MUST exist.</span><spanclass="rfc2119-assertion" id="submission-requirements-test-report-implementation">The <em>Test Report</em> MUST contain at least one implementation of a Consumer</span> (capable of understanding and performing all the operations described in the binding) and one Exposer (capable of handling all the operations and features described in the binding and optionally be able to create a valid TD). Additional implementations can be added even after the transition to the Current.</li>
@@ -593,7 +593,7 @@ <h3>Content</h3>
593
593
<li>Introduction</li>
594
594
<li>Binding Content:<ul>
595
595
<li>URL Format</li>
596
-
<li>Form Vocabulary Definition as Table</li>
596
+
<li>Form <ahref="#dfn-x-vocabulary-document">Vocabulary Definition as Table</a></li>
597
597
<li>Default and possible mappings to operations as a Table</li>
598
598
</ul>
599
599
</li>
@@ -608,8 +608,8 @@ <h3>Content</h3>
608
608
<h3>Documents</h3>
609
609
<p>The requirements for the machine-readable documents are as follows:</p>
610
610
<ul>
611
-
<li><spanclass="rfc2119-assertion" id="submission-requirements-doc-json-schema">There MUST be a JSON Schema (version to be defined) that allows validating the elements added by the entry.</span></li>
612
-
<li><spanclass="rfc2119-assertion" id="submission-requirements-doc-json-ld-context">There SHOULD be a JSON-LD Context and an ontology for the entry. Note that the lack of JSON-LD Context creates an RDF representation that will probably cause issues in RDF databases.</span></li>
611
+
<li><spanclass="rfc2119-assertion" id="submission-requirements-doc-json-schema">There MUST be a <ahref="#dfn-wot-x-binding-json-schema">JSON Schema</a> (version to be defined) that allows validating the elements added by the entry.</span></li>
612
+
<li><spanclass="rfc2119-assertion" id="submission-requirements-doc-json-ld-context">There SHOULD be a <ahref="#dfn-wot-x-binding-json-ld-context">JSON-LD Context</a> and an ontology for the entry. Note that the lack of JSON-LD Context creates an RDF representation that will probably cause issues in RDF databases.</span></li>
613
613
<li><spanclass="rfc2119-assertion" id="submission-requirements-doc-other">There MAY be other documents which are helpful to implementers, such as code, diagrams, and/or standalone examples.</span></li>
614
614
<li><spanclass="rfc2119-assertion" id="submission-requirements-doc-available-reviewer">These documents MUST be available to the reviewer.</span></li>
615
615
<li><spanclass="rfc2119-assertion" id="submission-requirements-doc-include">The reviewer MUST include these documents in their review.</span></li>
@@ -620,7 +620,7 @@ <h3>Documents</h3>
620
620
621
621
<sectionid="req-confl">
622
622
<h3>Conflict</h3>
623
-
<p><spanclass="rfc2119-assertion" id="submission-requirements-conflict">The binding entry SHOULD NOT conflict with other entries in the registry, such as its other versions or its dependents, by redefining the same concepts, such as redefining the URI Scheme, the vocabulary terms, or the default assignments.</span><spanclass="rfc2119-assertion" id="submission-requirements-conflict-deprecation">If a previously stable binding is being improved upon by the same organization, that previous binding MUST be deprecated once the new one reaches the <strong>stable</strong> status.</span></p>
623
+
<p><spanclass="rfc2119-assertion" id="submission-requirements-conflict">The binding entry SHOULD NOT conflict with other entries in the registry, such as its other versions or its <a>dependents</a>, by redefining the same concepts, such as redefining the URI Scheme, the vocabulary terms, or the default assignments.</span><spanclass="rfc2119-assertion" id="submission-requirements-conflict-deprecation">If a previously stable binding is being improved upon by the same organization, that previous binding MUST be deprecated once the new one reaches the <strong>stable</strong> status.</span></p>
624
624
</section>
625
625
626
626
<sectionid="req-redef">
@@ -630,7 +630,7 @@ <h3>Redefinition</h3>
630
630
631
631
<sectionid="req-deps">
632
632
<h3>Dependency</h3>
633
-
<p><spanclass="rfc2119-assertion" id="submission-requirements-dependency">If parts of the entry require the existence of another binding, i.e., has dependencies, the dependency MUST first be submitted as a separate entry.</span> For example, before LWM2M can be submitted, the CoAP Binding must exist.</p>
633
+
<p><spanclass="rfc2119-assertion" id="submission-requirements-dependency">If parts of the entry require the existence of another binding, i.e., has dependencies, the <a>dependency</a> MUST first be submitted as a separate entry.</span> For example, before LWM2M can be submitted, the CoAP Binding must exist.</p>
634
634
</section>
635
635
636
636
</section>
@@ -641,7 +641,7 @@ <h3>Dependency</h3>
641
641
<sectionid="registry">
642
642
<h2>Registry</h2>
643
643
644
-
<p>The following table defines the WoT Bindings Registry where each entry is a binding. Entries are ordered alphabetically according to their name.</p>
644
+
<p>The following table defines the <a>WoT Bindings Registry</a> where each entry is a binding. Entries are ordered alphabetically according to their name.</p>
645
645
646
646
<pclass="note">
647
647
The first entry is a placeholder example. It will be deleted once the first real entry is added. You can find the list of bindings that predate the registry mechanism at <ahref="https://github.com/w3c/wot-binding-templates/?tab=readme-ov-file#publications">this Readme file</a>.
0 commit comments