-
Notifications
You must be signed in to change notification settings - Fork 43
/
Copy pathreport11.html
1850 lines (1748 loc) · 89.3 KB
/
report11.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html><html lang="en"><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Web of Things (WoT) Architecture 1.1: Implementation Report</title>
<link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/general.css">
<style type="text/css" xml:space="preserve">
/*<![CDATA[*/
body {
margin: 2rem;
}
code {
background-color: rgba(27,31,35,.05);
border-radius: 3px;
margin: 0;
padding: .2em .4em;
}
h2 { font-size: 150% }
h3 { font-size: 120%; font-weight: bold }
h4 { font-size: 110%; font-weight: bold}
.tocline { list-style: none; }
table {
margin: auto;
width: 100%;
background-color: rgb(180,180,180);
border: black;
border-width: 1px;
}
th { background-color: rgb(180,255,180); }
th.rotate {
/* adjust as necessary... */
height: 180px;
white-space: nowrap;
}
th.rotate>div {
transform:
/* translate(25px, 51px)
rotate(315deg);
*/
rotate(90deg);
width: 30px;
}
th.rotate>div>span {
/* border-bottom: 1px solid #ccc;
*/
padding: 5px 10px;
}
td.baseassertion { background-color: rgb(234,255,234); }
td.tabassertion { background-color: rgb(234,255,255); }
td.defassertion { background-color: rgb(255,255,234); }
td.extraassertion { background-color: rgb(200,200,255); }
td.atrisk {
/* background-color: rgb(255,200,255) */
background-color: yellow;
}
td.result {
text-align: right;
padding: 2px 4px 2px 4px;
}
td.failed { background-color: rgb(255,200,200); }
td.passed { background-color: rgb(128,255,128); }
td.secure { background-color: rgb(0,255,0); }
td.missing { background-color: rgb(255,100,100); }
.comment { color: green; font-style: italic; }
.remove { text-decoration: line-through; color: black; }
.new { color: red; }
.working { background-color: rgb(255,234,234); padding:0.2em; }
.fill-in { background-color: rgb(255,234,234); }
table.testlist {
border: black;
border-width: 1px;
}
table.grammars th, table.commands th, able.attrs th, table.testlist th {
background-color: rgb(180,255,180);
font-size: 10pt;
vertical-align: top;
}
table.grammars td, table.commands td, table.attrs td, table.testlist td {
/* background-color: rgb(234,255,234); */
font-size: 10pt;
vertical-align: top;
}
table.attrs {
margin-top: 5px;
}
pre.example {
font-family: "Courier New", monospace;
white-space: pre;
background-color: rgb(204,204,255);
padding: 0.5em;
border: none;
border-width: 0;
margin-left: 0;
font-size: 100%;
width: 100%;
}
/*
.testimonial {
font-style: italic;
margin: 0 2rem 0 2rem;
}
*/
.at-risk {
background-color: yellow;
}
/*]]>*/
</style>
</head>
<body>
<div class="head">
<a href="http://www.w3.org/"><img src="https://www.w3.org/Icons/w3c_home" alt="W3C" width="72" height="48"></a>
<h1 id="h_ir">
Web of Things (WoT) Architecture 1.1:<br>
Implementation Report
</h1>
<p>
<b>Version</b>: 23 Nov 2023
</p>
<p>
<b>Editors</b>:<br>
Michael McCool (Intel)
</p>
<p class="copyright">
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
©
2017-2023
<a href="https://www.w3.org/">World Wide Web Consortium</a>.
<abbr title="World Wide Web Consortium">W3C</abbr><sup>®</sup>
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
<a rel="license" href="https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document" title="W3C Software and Document Notice and License">permissive document license</a> rules apply.
</p>
<hr title="Separator for header">
</div>
<h2 id="h_toc"><a id="toc" name="toc">Table of Contents</a></h2>
<ul>
<li class="tocline">1. <a href="#intro">Introduction</a>
<ul>
<li class="tocline">1.1 <a href="#objectives">Implementation Report objectives</a></li>
<li class="tocline">1.2 <a href="#non_objectives">Implementation Report non-objectives</a></li>
</ul>
</li>
<li class="tocline">2. <a href="#cr_work">Work during the Candidate Recommendation period</a></li>
<li class="tocline">3. <a href="#participate">Participating in the Implementation Report</a></li>
<li class="tocline">4. <a href="#pr_entrance_crit">Entrance criteria for the Proposed Recommendation phase</a></li>
<li class="tocline">5. <a href="#report_reqs">Implementation Report requirements</a>
<ul>
<li class="tocline">5.1 <a href="#DetailedReqs">Detailed requirements</a></li>
<li class="tocline">5.2 <a href="#NotesOnTesting">Notes on testing</a></li>
<li class="tocline">5.3 <a href="#out_of_scope">Out of scope</a></li>
</ul>
</li>
<!--
<li class="tocline">6. <a href="#sec-testimonials">Testimonials</a></li>
<ul id="testimonials-toc">
<li class="tocline">6.x <a href="#impl-ORG">ORG</a></li>
</ul>
-->
<li class="tocline">6. <a href="#test-systems">Systems</a></li>
<ul id="systems-toc">
<!--
<li class="tocline">6.x <a href="#impl-ORG">ORG</a></li>
-->
<li class="tocline">
6.1 <a href="#impl-dart_wot">dart_wot: Consumer and Discoverer</a></li>
<li class="tocline">
6.2 <a href="#impl-ditto-model">Eclipse Ditto WoT Model: Tool</a></li>
<li class="tocline">
6.3 <a href="#impl-ditto">Eclipse Ditto: TD Exposer</a></li>
<li class="tocline">
6.4 <a href="#impl-echonet-proxy">echonet-wot-proxy: Intermediary</a></li>
<li class="tocline">
6.5 <a href="#impl-editdor">Eclipse EdiTDor: Tool and Producer</a></li>
<li class="tocline">
6.6 <a href="#impl-fischertechnik">Fischertechnik Factory Simulator: Thing</a></li>
<li class="tocline">
6.7 <a href="#impl-fujitsu-ledbulb">fujitsu-ledbulb: TD Exposer</a></li>
<li class="tocline">
6.8 <a href="#impl-fujitsu-proxy">fujitsu-proxy: Intermediary</a></li>
<li class="tocline">
6.9 <a href="#impl-fujitsu-sensorledbulb">fujitsu-sensor: TD Exposer</a></li>
<li class="tocline">
6.10 <a href="#impl-hitachi-esp-idf">hitachi-esp-idf: Air quality sensor and acclerometer: TD Exposer</a></li>
<li class="tocline">
6.11 <a href="#impl-hitachi-nodegen">hitachi-nodegen: Node generator for Node-RED: TD Consumer</a></li>
<li class="tocline">
6.12 <a href="#impl-hitachi-nodered">hitachi-nodered: LED lamp: TD Exposer</a></li>
<li class="tocline">
6.13 <a href="#impl-hitachi-nrwotdisc">hitachi-nrwotdisc: WoT-Discovery Plugin for Node-RED: Discoverer</a></li>
<li class="tocline">
6.14 <a href="#impl-intel-nodejs">intel-nodejs: TD Exposer</a></li>
<li class="tocline">
6.15 <a href="#impl-intel-proxy">intel-proxy: Intermediary</a></li>
<li class="tocline">
6.16 <a href="#impl-intel-wot-ha">intel-wot-ha: TD Directory and TD Exposer</a></li>
<li class="tocline">
6.17 <a href="#impl-mqtt-experimental">MQTT Experimental: Thing</a></li>
<li class="tocline">
6.18 <a href="#NHK">NHK: Emulated WoT Devices</a></li>
<li class="tocline">
6.19 <a href="#impl-nodewot">Eclipse node-wot: Consumer and Exposer</a></li>
<li class="tocline">
6.20 <a href="#impl-philips-hue">philips-hue: Philips Hue Integration</a></li>
<li class="tocline">
6.21 <a href="#impl-playground">Thing Description Playground: Tool</a></li>
<li class="tocline">
6.22 <a href="#impl-python-flask">flask-tum: Custom Python Flask Things: Thing</a></li>
<li class="tocline">
6.23 <a href="#impl-riot-wot">RIOT WoT Implementation: TD Exposer</a></li>
<li class="tocline">
6.24 <a href="#impl-saywot">Siemens sayWoT!: Exposer and Consumer</a></li>
<li class="tocline">
6.25 <a href="#impl-sdf-wot-converter">SDF-WoT-Converter: Tool</a></li>
<li class="tocline">
6.26 <a href="#impl-siemens-logilab">SparTDD: Thing Description Directory</a></li>
<li class="tocline">
6.27 <a href="#impl-tinyiot">tiny-iot: TinyIoT Thing Directory</a></li>
<li class="tocline">
6.28 <a href="#impl-wot-coap-dns-sd">WoT CoAP Server supporting DNS-SD: TD Exposer</a></li>
<li class="tocline">
6.29 <a href="#impl-wot-experimental">WoT Experimental: Thing</a></li>
<li class="tocline">
6.30 <a href="#impl-wothive">WoT Hive directory</a></li>
<li class="tocline">
6.31 <a href="#impl-zion">Zion: A scalable Thing Description Directory</a></li>
</ul>
<li class="tocline">8. <a href="#security">Security</a></li>
<li class="tocline">9. <a href="#test_results">Test results</a>
<ul>
<!--
<li class="tocline">9.1 <a href="#automated_validation_results">Automated validation results</a></li>
<li class="tocline">9.2 <a href="#manual_validation_results">Manual validation results</a></li>
-->
<li class="tocline">9.1 <a href="#manual_validation_results">Validation results</a></li>
<!--
<li class="tocline">9.3 <a href="#test_interop">Interoperability results</a></li>
-->
</ul>
</li>
<li class="tocline">
<a href="#appendix">Appendix</a>
<ul>
<!--
<li class="tocline"><a href="#testspecB">Test specifications</a></li>
-->
<li class="tocline"><a href="#ack">Acknowledgements</a></li>
</ul>
</li>
</ul>
<h2 id="h_intro"><a id="intro" name="intro">1. Introduction</a> </h2>
<!--
<p>
The <a href="http://www.w3.org/TR/wot-architecture/">Web of Things (WoT) Architecture</a>
document entered the <a href="https://www.w3.org/TR/2022/CR-wot-architecture-2022MMDD/">Candidate Recommendation</a>
period for the second time on DD-MM-2022.
The planned date for entering Proposed Recommendation is DD-MM-2022.
</p>
-->
<p>
The <a href="http://www.w3.org/TR/wot-architecture11/">Web of Things (WoT) Architecture 1.1</a>
document was published as a
<a href="https://www.w3.org/TR/2023/CR-wot-architecture11-20230119/">Candidate Recommendation Snapshot</a>
on 19 January 2023
and as a
<a href="https://www.w3.org/TR/2023/PR-wot-architecture11-20230711/">Proposed Recommendation</a>
on 11 July 2023.
</p>
<p>
This document summarizes the results from the Web of Things (WoT) Architecture 1.1 implementer reports received and
describes the process that the Web of Things (WoT) Working Group followed in preparing this <em>Implementation Report (IR)</em>.
</p>
<h4 id="h_objectives"><a id="objectives" name="objectives">1.1 Implementation Report objectives</a></h4>
<ul>
<li>Must verify that the specification is implementable.</li>
</ul>
<h4 id="h_non_objectives"><a id="non_objectives" name="non_objectives">1.2 Implementation Report non-objectives</a></h4>
<ul>
<li>The IR does not attempt full conformance testing of implementations.</li>
</ul>
<p>
Results were based on data files submitted by implementers stating whether
or not their implementations conformed to the specification.
</p>
<h2 id="h_cr_work"><a id="cr_work" name="cr_work">2. Work done during the Candidate Recommendation period</a></h2>
<p>
During the CR period, the Working Group performed the following activities:
</p>
<ol>
<li>Clarification and improvement of the exposition of the specification</li>
<li>Disposing of comments that were communicated to the WG during the CR period.
These comments and their resolution are detailed in the
<a href="https://github.com/w3c/wot-architecture/issues">GitHub Issue tracker</a>.
<!--
with the label <a href="https://github.com/w3c/wot-architecture/issues?q=label%3A%22CR+period%22">CR period</a>.
-->
</li>
<li>Gathering of additional test inputs and resolution of any at-risk assertions.</li>
<li>Finalization of this Implementation Report.</li>
</ol>
<h2 id="h_participate"><a id="participate" name="participate">3. Participating in the Implementation Report</a></h2>
<p>
Implementers were invited to contribute to the assessment of the
<a href="https://www.w3.org/TR/2023/CR-wot-architecture11-20230119/">Web of Things (WoT) Architecture 1.1 Candidate Recommendation</a>
by submitting implementer reports describing the
coverage of their implementations with respect to the test assertions outlined
in the <a href="#manual_validation_results">table below</a>.
</p>
<p>
Implementer reports were collected through the W3C WoT Interest Group's
<a href="https://www.w3.org/2016/07/wot-ig-charter.html#scope">PlugFest</a> activity and collected
in the GitHub repository
<a href="https://github.com/w3c/wot-testing/tree/master/data/input_2022/Architecture">https://github.com/w3c/wot-testing</a>
under <code>data/input_2022/Architecture</code>.
</p>
<p>
Comments on this document, or requests made for
further information were posted to the Working Group's public
mailing list <a href="mailto:[email protected]">[email protected]</a>
(<a href="http://lists.w3.org/Archives/Public/public-wot-wg/">archive</a>)
and as issues on the GitHub repository
<a href="https://github.com/w3c/wot-architecture/issues">https://github.com/w3c/wot-architecture</a>.
</p>
<h2 id="h_pr_entrance_crit"><a id="pr_entrance_crit" name="pr_entrance_crit">4. Entrance criteria for the Proposed Recommendation phase</a></h2>
<p>
The Web of Things (WoT) Working Group established the following
entrance criteria for the Proposed Recommendation phase:
</p>
<ol>
<li>
Sufficient reports of implementation experience have been
gathered to demonstrate interoperabilty.
</li>
<li>
Specific Implementation Report requirements (<a href="#report_reqs">outlined below</a>) have been met.
</li>
<li>
The Working Group has formally addressed and responded to all
public comments received by the Working Group.
</li>
</ol>
<!--
<p>
All three of these criteria have been met.
Hard to count since some implementations have multiple components, and some are shared. Omit.
A total of N implementations were documented by M different organizations.
The testimonials below indicate the broad base of support
for the specification. All of the required features had at least
two implementations.
All of the optional features also received at least two implementations.
However, these optional features do not have
conformance requirements that have an impact on interoperability.
</p>
-->
<p>
In order to be included in the PR all features, whether optional
or required, need to have received at least two implementations.
At the time of publication of this report
all assertions have met this requirement.
</p>
<h2 id="h_report_reqs"><a id="report_reqs" name="report_reqs">5. Implementation Report requirements</a></h2>
<h4 id="h_DetailedReqs"><a id="DetailedReqs" name="DetailedReqs">5.1 Detailed requirements</a></h4>
<ol>
<!--
<li>
Testimonials from implementers are included in the IR when
provided to document the utility and implementability of the
specification.
</li>
-->
<li>
IR must cover all specified features in the specification. For
each feature the IR should indicate:
<ul>
<li>Feature status: required, optional, other.</li>
<li>Feature utility/usefulness based on feedback from implementers.</li>
<li>Implementability of the feature specification.</li>
</ul>
</li>
<!--
<li>
Feature status is a factor in test coverage in the report:
<ul>
<li>
Required specification features must have at least two implementations.
Implementations that do not implement a required
specification feature must document the reason for not implementing
the feature.
</li>
<li>
Optional specification features must have at least two implementations.
Implementations that do not implement an optional specification
feature should document the reason for not implementing the feature.
</li>
</ul>
</li>
-->
</ol>
<p>
Feature status is in practice indicated by
<a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a> assertions
associated with the feature. Features defined using any assertions
containing the words MUST are considered required.
Features defined using MAY and SHOULD assertions are considered optional.
</p>
<p>
Feature utility is indicated indirectly by the number of implementations
supporting each feature. In general, features with fewer implementations will
have a narrower scope, but may still be important for specific use cases.
</p>
<h4 id="h_NotesOnTesting"><a id="NotesOnTesting" name="NotesOnTesting">5.2 Notes on testing</a></h4>
<ol>
<li>
An implementer report must indicate the outcome of evaluating
the implementation with respect to each of the assertions defined in the specification.
Possible outcomes are <code>pass</code>, <code>fail</code>, or <code>not-impl</code> (not implemented).
</li>
<li>
In practice, implementer reports consist of CSV files for each implementation with the above
status assigned to each assertion in the specification. This report was
then automatically generated from these input files.
</li>
</ol>
<h4 id="h_out_of_scope"><a id="out_of_scope" name="out_of_scope">5.3 Out of scope</a></h4>
<p>This implementation Report will not cover:</p>
<ul>
<li>Conformance testing results</li>
<li>Interoperability testing results</li>
<li>All possible combinations of Things that TDs could describe (since this is an infinite set)</li>
</ul>
<p>
Although we did not formally test interoperability, we required two or more
independent implementations for all features in the specification
and tested general
interoperability at <a href="https://github.com/w3c/wot-testing/tree/main/events">plugfest events</a>.
</p>
<!--
<h2 id="h_testimonials"><a id="sec-testimonials" name="sec-testimonials">6. Testimonials</a></h2>
<p>
This section will contain testimonials from organizations
supporting the WoT specifications. This section is currently in progress.
</p>
<div id="testimonials">
</div>
-->
<h2 id="h_systems"><a id="test-systems" name="test-systems">6. Systems</a></h2>
<p>
This section contains descriptions of each of the implementations
of the WoT Architecture specification
from all organizations that submitted implementer reports to at least one
of the WoT specifications.
Each implementation represents a working system
that is based on the WoT Architecture.
However, only the following submitted implementation reports for the
WoT Architecture specification itself, and not all of these reported on
all features:
</p>
<ul>
<li><a href="#impl-dart_wot">dart_wot: Consumer and Discoverer</a></li>
<li><a href="#impl-ditto-model">Eclipse Ditto WoT Model: Tool</a></li>
<li><a href="#impl-ditto">Eclipse Ditto: TD Exposer</a></li>
<li><a href="#impl-fujitsu-proxy">fujitsu-proxy: Intermediary</a></li>
<li><a href="#impl-hitachi-esp-idf">hitachi-esp-idf: Air quality sensor and acclerometer: TD Exposer</a></li>
<li><a href="#impl-hitachi-nodegen">hitachi-nodegen: Node generator for Node-RED: TD Consumer</a></li>
<li><a href="#impl-hitachi-nodered">hitachi-nodered: LED lamp: TD Exposer</a></li>
<li><a href="#impl-intel-nodejs">intel-nodejs: TD Exposer</a></li>
<li><a href="#impl-nodewot">Eclipse node-wot: Consumer and Exposer</a></li>
<li><a href="#impl-playground">Thing Description Playground: Tool</a></li>
<li><a href="#impl-riot-wot">RIOT WoT Implementation: TD Exposer</a></li>
<li><a href="#impl-saywot">Siemens sayWoT!: Exposer and Consumer</a></li>
<li><a href="#impl-wot-experimental">WoT Experimental: Thing</a></li>
</ul>
<p>
For the purpose of establishing the implementability of the
WoT Architecture specification,
we only count systems with mostly independent code bases
as distinct implementations.
There are however some cases (documented in the following) where
implementations shared components but were still considered substantially
independent implementations. In cases where a substantial component
was shared across implementations the features supported by that
component were only counted once.
</p>
<!--
<p>
All test results from the first version of this specification were
reused to check for backward compatibility between this version
and the older specification.
Please see the
<a href="https://w3c.github.io/wot-thing-description/testing/report.html">implementation report
for the previous version of this specification</a> for additional
implementation descriptions.
</p>
<p>
Use of previous results does not imply support for the current specification
from organizations submitting those results.
In addition, some implementations are descriptive in nature and this does
not imply support from the organizations or companies producing the
described systems. Testimonials of support will be provided separately for
this purpose in the final report.
</p>
-->
<div id="systems-impl">
<!-- system implementation descriptions will be inserted here -->
<div class="impl" id="impl-dart_wot">
<h4 id="impl-dart_wot">dart_wot: Consumer and Discoverer</h4>
<p>
The library <code>dart_wot</code> is a WoT Scripting API implementation written in the Dart programming language, aimed at bringing Web of Things support to the Dart/Flutter ecosystem.
</p>
<p>
It supports consuming and discovering TDs, providing protocol bindings for HTTP, CoAP, and MQTT.
Its supported security mechanisms include DTLS (CoAP), TLS (HTTP, MQTT), Basic and Bearer authentication (HTTP), PSK (CoAP), and username/password authentication (MQTT).
Furthermore, <code>dart_wot</code>'s CoAP binding offers experimental support for ACE-OAuth (RFC 9200), an authorization and authentication framework for constrained environments.
</p>
<p>
<strong>Usage:</strong> <code>dart_wot</code> can be included in Dart and Flutter projects as a dependency. In Flutter apps, all platforms are supported, with macOS and iOS (where CoAPS support is limited) and Web browsers (where CoAP is not supported at all) as partial exceptions.
</p>
<p>
<strong>Public Repository:</strong> https://github.com/namib-project/dart_wot
</p>
<p>
<strong>pub.dev Entry:</strong> https://pub.dev/packages/dart_wot
</p>
<p>
<strong>Contributing Member Organizations:</strong> Invited Experts
</p>
</div><div class="impl" id="impl-ditto-model">
<h4 id="impl-ditto-wot-model">Eclipse Ditto WoT Model: Tool</h4>
<p>
Eclipse Ditto offers a Java Module to use TDs and TMs inside Java
environments with concepts native to Java, e.g. providing a builder API for
creating new TM/TD instances and rendering those to JSON strings and vice
versa.
</p>
<p><b>Usage:</b> Library</p>
<p>
<b>Public Repository:</b>
https://github.com/eclipse/ditto/tree/master/wot/model
</p>
<p><b>Contributing Member Organizations:</b> Bosch.IO</p>
</div><div class="impl" id="impl-ditto">
<h4 id="impl-ditto-WoT">Eclipse Ditto: TD Exposer</h4>
<p>
A service that provides APIs for managing digital twins and interacting with
the abstracted devices. Fetches linked Thing Models of digital twins and
provides instance specific Thing Descriptions for them.
</p>
<p><b>Usage:</b> Service</p>
<p><b>Public Repository:</b> https://github.com/eclipse/ditto</p>
<p>
<b>Website:</b> https://www.eclipse.org/ditto/basic-wot-integration.html
</p>
<p><b>Contributing Member Organizations:</b> Bosch.IO</p>
</div><div class="impl" id="impl-echonet-proxy">
<h4>echonet-wot-proxy: Intermediary</h4>
<p>
This is an intermediary that connects ECHONET Lite devices into the W3C WoT and allows WoT clients to interact with them via provided TDs.
</p><p>
This intermediary extends the node-wot library.
</p>
</div><div class="impl" id="impl-editdor">
<h4 id="impl-editdor">Eclipse EdiTDor: Tool and Producer</h4>
<p>
The Eclipse EdiTDor implementation is a web application for simply designing
W3C Thing Descriptions and Thing Models.
</p>
<p><b>Usage:</b> Web Application</p>
<p>
<b>Public Repository:</b> https://github.com/eclipse/editdor
<b>Website:</b> https://eclipse.github.io/editdor/
</p>
<p><b>Contributing Member Organizations:</b> Siemens AG, Bosch.IO</p>
</div><div class="impl" id="impl-fischertechnik">
<h4 id="impl-fischertechnik">Fischertechnik Factory Simulator: Thing</h4>
<p>
This TM focused implementation is built upon the <a href="https://www.fischertechnik.de/en/service/elearning/simulating/fabrik-simulation-24v">Fischertechnik Factory Simulator</a>.
The TMs are written by hand, together with the relationships.
The TMs are then consumed by Eclipse Thingweb node-wot and is the reason why only TMs are submitted instead of TMs and
the corresponding TDs.
</p>
<p>
<b>Usage:</b> To be consumed by tools like Eclipse Thingweb node-wot
</p>
<p>
</p>
<p><b>Contributing Member Organizations:</b>Siemens AG and TU Munich (not member)</p>
</div><div class="impl" id="impl-fujitsu-ledbulb">
<h4>fujitsu-ledbulb: TD Exposer</h4>
<p>
The Fujitsu ledbulb is a Wi-Fi controllable LED bulb that can be changed brightness and color. In addition, the light can be gradually turned off or turned on at a specified time.
</p>
</div><div class="impl" id="impl-fujitsu-proxy">
<h4>fujitsu-proxy: Intermediary</h4>
<p>
Fujitsu's proxy creates a shadow of the device in the proxy, allowing consumers to control the actual device by accessing the shadow. Even if the actual device does not have an authentication mechanism, the proxy provides an authentication mechanism instead to enable secure access. Another advantage is that even if multiple devices have different protocol bindings, they can be accessed using one protocol. It also has a directory for discovering networked devices, creating their shadows, and registering them. </p>
<p>
The proxy is implemented in Java.
</p>
<p>
This proxy is provided as a product in Japan. The product page is below (Japanese only).
https://www.fujitsu.com/jp/products/network/carrier-router/wideareanetwork/virtuora-mx/
</p>
</div><div class="impl" id="impl-fujitsu-sensorledbulb">
<h4>fujitsu-sensor: TD Exposer</h4>
<p>
The Fujitsu sensor is a sensor with temperature, humidity, and air pressure, and can be communicated through Wi-Fi to get data. This sensor was used to collect environmental data in agriculture and factories.
</p>
</div><div class="impl" id="impl-hitachi-esp-idf">
<h4>hitachi-esp-idf: Air quality sensor and acclerometer: TD Exposer</h4>
<p>
This is an example of a Thing implemented on a microcontroller.
It can exporting the Thing's sensor reading via HTTP REST API,
and advertise its own Thing Description using DNS-SD/mDNS.
</p>
</div><div class="impl" id="impl-hitachi-nodegen">
<h4>hitachi-nodegen: Node generator for Node-RED: TD Consumer</h4>
<p>
<a href="https://github.com/node-red/node-red-nodegen">Node generator</a> is
command line tool to generate
<a href="https://nodered.org/">Node-RED</a> node modules from several
various sources including Thing Description of Web of Things. Using this
tool, node developers can dramatically reduce their time to implement
Node-RED node modules.
</p>
</div><div class="impl" id="impl-hitachi-nodered">
<h4>hitachi-nodered: LED lamp: TD Exposer</h4>
<p>
This is an example of a Thing implemented in Node-RED.
It can turn on and off a LED connected to Raspberry Pi's GPIOs
and notify changes in LED status.
It can also advertise its own Thing Description using DNS-SD/mDNS.
</p>
</div><div class="impl" id="impl-hitachi-nrwotdisc">
<h4>hitachi-nrwotdisc: WoT-Discovery Plugin for Node-RED: Discoverer</h4>
<p>
This plugin uses wot-discovery functionality
and make it easy to import Things into Node-RED flow editor.
The plugin discovers Things connected on the local area network or registered
in the Thing Description Directory, and converts them into functional blocks
that can be used in Node-RED.
</p>
</div><div class="impl" id="impl-intel-nodejs">
<h4>intel-nodejs: TD Exposer</h4>
<p>
Two services based on a shared NodeJS codebase (not using node-wot):
</p>
<ul>
<li>A simple camera service that interfaces
with V4L (Video for Linux) to capture still images
from a USB camera.
</li>
<li>A simple text-to-speech output service based on espeak.
</li>
</ul>
<p><b>Usage:</b> Exposer</p>
<p><b>Contributing Member Organizations:</b> Intel</p>
</div><div class="impl" id="impl-intel-proxy">intel-proxy: Intermediary
<h4>intel-proxy: Intermediary</h4>
<p>
This is a reverse proxy service that provides
authentication (via various mechanisms indicated by the schemes indicated in the Thing
Description) and encrypted transport (TLS) termination.
The reverse proxy service was made accessible over a secure tunnel,
and depending on the circumstances,
can be run in the cloud, on a gateway computer, or locally on a device.
</p>
<p>
The secure endpoints provided by this service are not given in TDs for the
service itself, but added to the TDs for the Things it services.
</p>
<p><b>Usage:</b> Intermediary</p>
<p><b>Contributing Member Organizations:</b> Intel</p>
</div><div class="impl" id="impl-intel-wot-ha">
<h4>intel-wot-ha: TD Directory and TD Exposer</h4>
<p>
A simple integration of WoT into Home Assistant.
A service interrogates the metadata made available from Home Assistant on
its external RESTful API. It then generates TDs for Home Assistant entities
that can be accessed via this API and makes then available via
a TD Directory service that follows the WoT Discovery specification.
WoT Consumers can then access the TD Directory to find TDs for
entities supported by Home Assistant and access these services
using WoT affordance abstractions.
</p>
<p><b>Usage:</b> Directory and Exposer</p>
<p><b>Contributing Member Organizations:</b> Intel</p>
</div><div class="impl" id="impl-mqtt-experimental">
<h4 id="impl-mqtt-experimental">MQTT Experimental: Thing</h4>
<p>
The MQTT Experimental is an MQTT-based Thing implementation that aims to test different WoT operations together with the Data Schema variations that
can exist in a TD.
It is implemented in Python and can act as a way to verify interoperability between different MQTT Binding implementations.
</p>
<p>
<b>Usage:</b> Command line
</p>
<p>
<b>Public Repository:</b> https://github.com/egekorkan/wot-implementations/tree/master/mqtt-online
</p>
<p><b>Contributing Member Organizations:</b>Siemens AG</p>
</div><div class="impl" id="NHK">
<h4>NHK: Emulated WoT Devices</h4>
<p>
<a href="https://github.com/w3c/wot-testing/tree/main/events/2021.09.Online/Projects/NHK">WoT device emulator (Android
App) </a>
<a href="https://github.com/nhkrd/antwapp4hc">Hybrid TV Emulator AndroidTV App</a>
</p><ul>
<li> Android app becomes a WoT Device.
</li>
</ul>
<p></p>
</div><div class="impl" id="impl-nodewot">
<h4 id="impl-node-wot">Eclipse node-wot: Consumer and Exposer</h4>
<p>
The Eclipse node-wot implementation is a Node.js-based framework for WoT Servients.
It features an implementation of the WoT Scripting API to both consume TDs
to instantiate Consumed Things and produce Exposed Things that provide a TD.
The Eclipse node-wot implementation supports several Protocol Bindings including
HTTP, CoAP, WebSockets, MQTT, Firestore, OPC-UA, Modbus, M-Bus and NETCONF with
corresponding security mechanisms such as DTLS (CoAP); TLS (HTTP, MQTT), Basic,
Digest, and Bearer Token authentication (HTTP), PSK (CoAP), and
username/password authentication (MQTT).
</p>
<p>
<b>Usage:</b> It can be included in bigger projects as a dependency,
used as a Command Line Interface or as a browser library.
</p>
<p>
<b>Public Repository:</b> https://github.com/eclipse/thingweb.node-wot
</p>
<p>
<b>Contributing Member Organizations:</b> Siemens AG, Invited Experts
</p>
</div><div class="impl" id="impl-philips-hue">
<h4 id="impl-philips-hue">philips-hue: Philips Hue Integration</h4>
<p>
This implementation leverages the already developed Philips Hue devices. The TDs for them are written by hand and show the use of WoT for brownfield
devices. Philips Hue uses API Key in the URI, which is one of the features of the TD 1.1.
</p>
<p>
<b>Usage:</b> The TDs of the devices can be consumed and interacted with.
</p>
<p>
<b>Public Repository:</b> https://github.com/tum-esi/wot-sys/tree/master/Devices/PhilipsHUE
</p>
<p><b>Contributing Member Organizations:</b>Siemens AG and TU Munich (non-member)</p>
</div><div class="impl" id="impl-playground">
<h4 id="impl-playground">Thing Description Playground: Tool</h4>
<p>
The Thing Description Playground implementation is a set of tools that
allows one to validate TDs, as well to transform them into different
representations such as OpenAPI and AsyncAPI or to manipulate TDs to add or remove default terms and values.
It also allows to detect implemented assertions of the TD spec by looking at a TD, which is how the
implementation report for the TD is generated.
</p>
<p>
<b>Usage:</b> It can be included in bigger projects as a dependency, used as
a Command Line Interface or as a web application library.
</p>
<p>
<b>Public Repository:</b> https://github.com/thingweb/thingweb-playground
<b>Website:</b> http://plugfest.thingweb.io/playground/
</p>
<p><b>Contributing Member Organizations:</b>Siemens AG</p>
</div><div class="impl" id="impl-python-flask">
<h4 id="impl-python-flask">flask-tum: Custom Python Flask Things: Thing</h4>
<p>
Custom implementation pattern using the Flask library for creating an HTTP server that exposes a TD.
This pattern is used in many devices that have been developed.
It is not a framework like Eclipse Thingweb node-wot, more like a copy-paste driven implementation pattern.
</p>
<p>
<b>Usage:</b> Command line
</p>
<p>
<b>Public Repository:</b> All that start with "flask" at https://github.com/tum-esi/wot-sys/tree/master/Devices
</p>
<p><b>Contributing Member Organizations:</b>Siemens AG and TU Munich (non-member)</p>
</div><div class="impl" id="impl-riot-wot">
<h4>RIOT WoT Implementation: TD Exposer</h4>
<p>
WoT modules for RIOT, a real-time operating system for the Internet of Things.
</p>
<p>
The implementation provides data structures and serialization capabilities for generating and retrieving a RIOT device's TD using CoAP and DTLS (in PSK and RPK mode).
The TD can be both discovered using <code>/.well-known/wot</code> and the CoRE Link Format (exposing the TD resource via <code>/.well-known/core</code>).
Furthermore, the implementation includes a code generator that allows for translating an input Thing Model or Thing Description into C structures which will be used for serializing the device's TD.
</p>
<p>
At the time of writing, the implementation is not yet part of the RIOT upstream repository and only lives in a RIOT fork.
However, the authors are working on integrating it into the RIOT upstream project.
</p>
<p>
<strong>Usage:</strong> RIOT-based applications can include the WoT modules via RIOT's Make-based build system.
</p>
<p>
<strong>Example applications (usable with ESP32s) can be found here:</strong> https://github.com/namib-project/wot-nodes
</p>
<p>
<strong>Contributing Member Organizations:</strong> Invited Experts
</p>
</div><div class="impl" id="impl-saywot">
<h4 id="impl-saywot">Siemens sayWoT!: Exposer and Consumer</h4>
<p>
sayWoT! is an industrial-grade implementation that allows integration of devices
into Siemens software products like
<a href="https://new.siemens.com/global/en/products/automation/industry-software/apps-and-digital-services-for-process-industry.html">Asset Performance Suite</a>,
<a href="https://new.siemens.com/global/en/products/buildings/automation/desigo/building-management/desigo-cc.html">Desigo CC</a>
in a semantically-described and standardized way.
sayWoT! is implemented in golang for optimal scalability and cross-architecture compatability.
</p>
<p><b>Usage:</b> Service in the cloud or on premise, Command Line Interface</p>
<p>
<b>Website:</b> https://www.evosoft.com/en/digitalization-offering/saywot/
</p>
<p><b>Contributing Member Organizations:</b> Siemens AG</p>
</div><div class="impl" id="impl-sdf-wot-converter">
<h4>SDF-WoT-Converter: Tool</h4>
<p>
The SDF-WoT-Converter is a Python-based conversion tool between WoT data models (TDs and TMs) and the <a href="https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf/">Semantic Definition Format (SDF)</a>, an IETF specification that strives to be a common data format for IoT device descriptions.
The implementation provides a library API for using it in Python projects as well as a command-line interface after installing it via the Python package manager <code>pip</code>.
Besides converting between WoT data models and SDF, the implementation also supports the conversion between TDs and TMs.
</p>
<p>
<strong>Usage:</strong> Library or Command Line
</p>
<p>
<strong>Public Repository:</strong> https://github.com/JKRhb/sdf-wot-converter-py
</p>
<p>
<strong>Python Package Index Entry:</strong> https://pypi.org/project/sdf-wot-converter/
</p>
<p><strong>Contributing Member Organizations:</strong> Invited Experts</p>
</div><div class="impl" id="impl-siemens-logilab">
<h4 id="impl-siemens-logilab-WoT">SparTDD: Thing Description Directory</h4>
<p>
SparTDD is an implementation of the W3C Web of Things
Thing Description Directory. There are two main components.
The API of the TDD is written in Python using <a href="https://flask.palletsprojects.com/">Flask</a>.
The data is stored in RDF in a <a href="https://jena.apache.org/documentation/archive/serving_data/fuseki1.html">Apache Jena Fuseki</a>
SPARQL endpoint. A demo can be found <a href="https://siemens-wot.demo.logilab.fr/">here</a>.
</p>
<p><b>Usage:</b>Directory</p>
<p><b>Contributing Member Organizations:</b>Siemens</p>
</div><div class="impl" id="impl-tinyiot">
<h4 id="impl-tinyiot">tiny-iot: TinyIoT Thing Directory</h4>
<p>
This is an implementation of the W3C Web of Things (WoT) Thing Description Directory (TDD).
This directory is designed to be lightweight and portable, enabling deployment on the edge.
It uses a layered architecture to allows the addition of different storage backends to server high scalability needs.
</p><p>
The directory advertises itself in local networks using DNS-SD.
It comes with the Things and Notification APIs, as well as JSONPath search support (non-normative).
The directory performs fine-grained access control with the help of locally defined rules and an OpenID Connect server.
</p>
<p><b>Usage:</b> Directory</p>
<p><b>Public Repository:</b> https://github.com/TinyIoT/thing-directory</p>
<p>
<b>Website:</b> https://github.com/TinyIoT
</p>
<p><b>Contributing Member Organizations:</b> The parent fork has been developed as part of LinkSmart by Fraunhofer-Gesellschaft</p>
</div><div class="impl" id="impl-wot-coap-dns-sd">
<h4>WoT CoAP Server supporting DNS-SD: TD Exposer</h4>
<p>
Basic Rust-based CoAP server, providing a TD resource that can be discovered using DNS-SD and
multicast DNS.
</p>
<p>
<strong>Usage:</strong> The application can be started from the command line using Rust's package manager cargo.
</p>
<p>
<strong>Public Repository:</strong> https://github.com/JKRhb/wot-coap-dns-sd
</p>
<p>
<strong>Contributing Member Organizations:</strong> Invited Experts
</p>
</div><div class="impl" id="impl-wot-experimental">
<h4 id="impl-wot-experimental">WoT Experimental: Thing</h4>
<p>
The WoT Experimental is a collection of Thing implementations that aims to test different features of the TD
specification such as WoT operations, Data Schema variations and API Key usage in Body.
</p>
<p>
<b>Usage:</b> Command line
</p>
<p>
<b>Public Repository:</b> https://github.com/egekorkan/wot-implementations
</p>
<p><b>Contributing Member Organizations:</b>Siemens AG</p>
</div><div class="impl" id="impl-wothive">
<h4 id="impl-wothive-dir">WoT Hive directory</h4>
<p>
WoT Hive is an implementation of a W3C Web of Things directory. This implementation is compliant with the standard specification but aims at providing enriched features thanks to the usage of other W3C standards related to Semantic Web technologies.
</p>
<p><b>Usage:</b> Directory</p>
<p><b>Public Repository:</b> https://github.com/oeg-upm/wot-hive</p>
<p>
<b>Website:</b> https://github.com/oeg-upm/wot-hive
</p>
<p><b>Contributing Member Organizations:</b> Universidad Politécnica de Madrid</p>
</div><div class="impl" id="impl-zion">
<h4 id="impl-zion">Zion: A scalable Thing Description Directory</h4>
<p>
Zion implements the standard TDD APIs with a set of extentions to cover the use cases of <a href="https://vaimee.com/">VAIMEE</a>
</p><p>
</p><p>Zion employes the best open source technologies to provide a scalable TDD service. Zion wants to be <a href="https://github.com/vaimee/tdd-workload-generator">fast</a>, ease to use
and flexible. Our goal is to build a service tailored for entrepise use and scalable to different deployments from small set of TDs in the Edge to high loads of the Cloud.
Currently, Zion is written in Typescript and supports the following features:</p>
<ul>
<li><a href="https://w3c.github.io/wot-discovery/#introduction-mech">Introduction methods</a> :
<ul>
<li>DNS-SD</li>
<li>Well-known URL</li>
<li>CoRE Link Format and <code>/.well-known/core</code></li>
</ul>
</li>
<li>Standard API:
<ul>
<li>CRUD operations on the collection of TDs</li>
<li>JSONPath queries compliant with IETF JSONPath standard <a href="https://datatracker.ietf.org/doc/html/draft-ietf-jsonpath-base#section-3.5.8">draft 5</a></li>
<li>Pagination support</li>
</ul>
</li>
<li>Basic support for authentication and authorization</li>
</ul>
<p></p>
<p><b>Usage:</b> Directory</p>
<p><b>Public Repository:</b> https://github.com/vaimee/zion</p>
<p>
<b>Website:</b> https://zion.vaimee.com/
</p>
<p><b>Contributing Member Organizations:</b> Invited Experts </p>
</div></div>
<h2 id="h_security"><a id="security" name="security">8. Security</a></h2>
<p>
The
<a href="https://www.w3.org/TR/wot-architecture">Web of Things (WoT) Architecture</a>
specification describes systems that include features to support security.
Functional aspects of assertions associated with security features are validated
in the same fashion as other functional features.
<!--
In addition, however, the
<a href="https://www.w3.org/2022/07/wot-wg-2022.html">Web of Things (WoT) WG Charter</a>
requires the development of a test plan.
An appropriate security test plan, including a description
of how existing web service penetration testing tools can be used,
in addition to a description of more general security and privacy considerations,
is included in
<a href="http://www.w3.org/TR/wot-security">Web of Things (WoT) Security and Privacy Guidelines</a>.
-->
</p>
<h2 id="h_test_results"><a id="test_results" name="test_results">9. Test results</a></h2>
<p>
The aim of this section is to summarize the assertions from the
<a href="http://www.w3.org/TR/wot-architecture">Web of Things (WoT) Architecture</a>
document and summarize the results from the implementation
reports received in the CR period.
The tables in each section below lists all assertions derived from the
<a href="http://www.w3.org/TR/wot-architecture">Web of Things (WoT) Architecture</a>
document.
<!--
The results are broken into two parts:
those for which automated testing has been implemented,
and those for which it has not and manual testing and reporting was necessary.
-->
</p>
<p>
The headers for these tables are described as follows:
</p>