Repository navigation
Expand file tree
/
Copy pathindex.html
More file actions
2129 lines (2119 loc) · 235 KB
/
Copy pathindex.html
File metadata and controls
2129 lines (2119 loc) · 235 KB
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" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8" />
<title>Application Capability</title>
<meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport" />
<style>
main,
main>article,
main>article>div {
background:inherit;
}
body {
counter-reset:section sub-section appendix sub-appendix;
}
code, samp { color: #e00; }
pre code, pre samp { color: var(--text); }
dfn { font-weight:inherit; }
.do.fragment a { border-bottom:0; }
.do.fragment a:hover { background:none; border-bottom:0; }
section figure pre { margin:1em 0; display:block; }
cite .bibref { font-style: normal; }
.tabs nav ul li { margin:0; }
div.issue, div.note, div.warning {
clear: both;
margin: 1em 0;
position: relative;
}
div.issue h3, div.note h3,
div.issue h4, div.note h4,
div.issue h5, div.note h5 {
margin:0;
font-weight:normal;
font-style:normal;
font-size:1em;
}
div.issue h3 > span, div.note h3 > span,
div.issue h4 > span, div.note h4 > span,
div.issue h5 > span, div.note h5 > span,
figure.example > figcaption > span {
text-transform: uppercase;
}
div.issue h3, div.issue h4, div.issue h5 {
color:var(--issueheading-text);
}
div.note h3, div.note h4, div.note h5 {
color:var(--noteheading-text);
}
figure.example figcaption {
color:var(--exampleheading-text);
}
main figure {
text-align:left;
}
figure[id] {
position:relative;
padding:0.5em;
}
figure[id] figcaption {
font-style:normal;
font-size:1em;
}
figure.example figcaption span + span {
text-transform:initial;
}
.copyright + hr {
border-style: solid;
}
header address a[href] {
float: right;
margin: 1rem 0 0.2rem 0.4rem;
background: transparent none repeat scroll 0 0;
border: medium none;
text-decoration: none;
}
header address img[src*="logos/W3C"] {
background: #1a5e9a none repeat scroll 0 0;
border-color: #1a5e9a;
border-image: none;
border-radius: 0.4rem;
border-style: solid;
border-width: 0.65rem 0.7rem 0.6rem;
color: white;
display: block;
font-weight: bold;
}
main article > h1 {
font-size: 220%;
font-weight:bold;
}
#acknowledgements ul { padding: 0; margin:0; }
#acknowledgements li { display:inline; }
#acknowledgements li:after { content: ", "; }
#acknowledgements li:last-child:after { content: ""; }
dd .contributed {
user-select: none;
}
aside.do { overflow:inherit; }
aside.do blockquote {
padding: 0; border: 0; margin: 0;
}
dl[id^="document-"] ul {
padding-left:0;
list-style-type:none;
}
dl [rel~="odrl:action"],
dl [rel~="odrl:action"] li {
display: inline;
}
dl [rel~="odrl:action"] li:after {
content: ", ";
}
dl [rel~="odrl:action"] li:last-child:after {
content: "";
}
aside section > .toc,
aside section > .toc ol {
margin-left: revert;
}
aside section > .toc li li {
margin-left: 1em;
font-size: revert;
}
.toc li > p:first-child {
margin-bottom:initial;
}
table {
border-collapse:collapse;
}
table + table {
margin-top:2em;
}
caption {
text-align:left;
padding:0 0.25em 0.25em;
margin-bottom: 1em;
font-size: 1em;
font-style: revert;
font-weight: bold;
border-bottom: 1px solid;
}
caption, tbody, tfoot {
border-bottom:2pt solid #ccc;
}
thead,
thead th[colspan] {
border-bottom:1pt solid #ccc;
}
[rowspan] { vertical-align: bottom; }
tbody [rowspan] { vertical-align: middle; }
tbody th[scope="rowgroup"] {
border-bottom:3pt double #ccc;
}
tr {
border-bottom:1pt solid #ccc;
}
th, td {
padding:0.25em;
font-size:0.923em;
word-wrap:normal;
}
table ul,
table ol,
table li,
table p,
table dd {
margin:0;
text-align:left;
}
table ul,
table ol {
padding-left:1em;
}
tfoot td > * + * {
margin-top:1em;
}
tfoot dd:after { content: "\A"; white-space:pre; }
tfoot dt, tfoot dd { display:inline; }
tfoot dd { margin-left: 0.5em; }
tfoot dd + dt { margin-top:0; }
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]):not([id=exit-criteria]) {
counter-increment:section;
counter-reset:sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]) section:not([id$=references]):not([id=exit-criteria]) {
counter-increment:sub-section;
counter-reset:sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]) section:not([id$=references]):not([id=exit-criteria]) section {
counter-increment:sub-sub-section;
counter-reset:sub-sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]) section:not([id$=references]):not([id=exit-criteria]) section section {
counter-increment:sub-sub-sub-section;
counter-reset:sub-sub-sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]):not([id=exit-criteria]):not([id^=table-of-]):not([id^=list-of-]) > h2:before {
content:counter(section) ".\00a0";
}
section:not([id$=references]):not([id^=changelog]):not([id=exit-criteria]):not([id^=table-of-]):not([id^=list-of-]) > h3:before {
content:counter(section) "." counter(sub-section) "\00a0";
}
section > h4:before {
content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0";
}
article section.appendix {
counter-increment:appendix;
counter-reset:sub-appendix;
}
article section[class~=appendix]:not([id=abstract]):not([id=sotd]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]):not([id=exit-criteria]) section {
counter-increment:sub-appendix;
counter-reset:sub-sub-appendix;
}
section.appendix > h2:before {
content:counter(appendix, upper-alpha) ".\00a0";
}
section.appendix section > h3:before {
content:counter(appendix, upper-alpha) "." counter(sub-appendix) "\00a0";
}
</style>
<link href="https://www.w3.org/StyleSheets/TR/2021/base.css" media="all" rel="stylesheet" title="W3C-Base" />
<link href="https://www.w3.org/StyleSheets/TR/2021/dark.css" media="(prefers-color-scheme: dark)" rel="stylesheet" />
<link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" />
<script async="" src="https://dokie.li/scripts/dokieli.js"></script>
</head>
<body about="" prefix="as: https://www.w3.org/ns/activitystreams# cito: http://purl.org/spar/cito/ dcat: http://www.w3.org/ns/dcat# dcterms: http://purl.org/dc/terms/ doap: http://usefulinc.com/ns/doap# dpv: https://w3id.org/dpv# earl: http://www.w3.org/ns/earl# ldp: http://www.w3.org/ns/ldp# mem: http://mementoweb.org/ns# odrl: http://www.w3.org/ns/odrl/2/ owl: http://www.w3.org/2002/07/owl# prov: http://www.w3.org/ns/prov# qb: http://purl.org/linked-data/cube# rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# rel: https://www.w3.org/ns/iana/link-relations/relation# risk: https://w3id.org/dpv/risk# schema: http://schema.org/ skos: http://www.w3.org/2004/02/skos/core# spec: http://www.w3.org/ns/spec# xsd: http://www.w3.org/2001/XMLSchema#">
<main>
<article about="">
<div class="head">
<h1 property="schema:name">Application Capability</h1>
<p id="w3c-state"><a href="https://www.w3.org/standards/types/#reports" rel="rdf:type">Draft Community Group Report</a>, <time datetime="2026-10-24T00:00:00Z">24 October 2026</time></p>
<details open="">
<summary>More details about this document</summary>
<dl id="document-identifier">
<dt>This version</dt>
<dd><a href="https://dokieli.github.io/application-capability/">https://dokieli.github.io/application-capability/</a></dd>
</dl>
<dl id="document-latest-published-version">
<dt>Latest published version</dt>
<dd><a href="https://dokieli.github.io/application-capability/">https://dokieli.github.io/application-capability/</a></dd>
</dl>
<dl id="document-history">
<dt>History</dt>
<dd><a href="https://github.com/dokieli/application-capability/commits/main/index.html">Commit history</a></dd>
</dl>
<dl id="document-editors">
<dt>Editors</dt>
<dd data-editor-id="46140" id="Sarven-Capadisli"><span about="" rel="schema:creator schema:editor schema:author"><span about="https://csarven.ca/#i" typeof="schema:Person"><a href="https://csarven.ca/" rel="schema:url"><span about="https://csarven.ca/#i" property="schema:name"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span></span> <span class="contributed">(v0.3.1415)</span></dd>
<dd data-editor-id="129283" id="Virginia-Balseiro"><span about="" rel="schema:editor schema:author"><span about="https://virginiabalseiro.com/#me" typeof="schema:Person"><a href="https://virginiabalseiro.com/" rel="schema:url"><span about="https://virginiabalseiro.com/#me" property="schema:name"><span property="schema:givenName">Virginia</span> <span property="schema:familyName">Balseiro</span></span></a></span></span> <span class="contributed">(v0.3.1415)</span></dd>
</dl>
<dl id="document-published">
<dt>Published</dt>
<dd><time content="2024-05-31T00:00:00Z" datatype="xsd:dateTime" datetime="2024-05-31T00:00:00Z" property="schema:datePublished">2024-05-31</time></dd>
</dl>
<dl id="document-modified">
<dt>Modified</dt>
<dd><time content="2026-10-24T09:17:31.246Z" datatype="xsd:dateTime" datetime="2026-10-24T09:17:31.246Z" property="schema:dateModified">2026-10-24</time></dd>
</dl>
<dl id="document-feedback">
<dt>Feedback</dt>
<dd><a href="https://github.com/dokieli/application-capability" rel="doap:repository">GitHub dokieli/application-capability</a> (<a href="https://github.com/dokieli/application-capability/pulls">pull requests</a>, <a href="https://github.com/dokieli/application-capability/issues/new">new issue</a>, <a href="https://github.com/dokieli/application-capability/issues" rel="doap:bug-database">open issues</a>)</dd>
</dl>
<dl id="document-language">
<dt>Language</dt>
<dd><span content="en" lang="" property="dcterms:language" xml:lang="">English</span></dd>
</dl>
<dl id="document-type">
<dt>Document Type</dt>
<dd><a href="http://usefulinc.com/ns/doap#Specification" rel="rdf:type">Specification</a></dd>
<dd><a href="http://schema.org/TechArticle" rel="rdf:type">TechArticle</a></dd>
</dl>
<dl id="document-version">
<dt>Version</dt>
<dd><span lang="" property="schema:version" xml:lang="">0.3.1415</span></dd>
</dl>
<dl id="document-policy">
<dt>Policy</dt>
<dd>
<dl id="document-policy-offer" rel="odrl:hasPolicy" resource="#document-policy-offer" typeof="odrl:Policy">
<dt>Rule</dt>
<dd><a about="#document-policy-offer" href="https://www.w3.org/TR/odrl-vocab/#term-Offer" typeof="odrl:Offer">Offer</a></dd>
<dt>Unique Identifier</dt>
<dd><a href="https://dokieli.github.io/application-capability/#document-policy-offer" rel="odrl:uid">https://dokieli.github.io/application-capability/#document-policy-offer</a></dd>
<dt>Target</dt>
<dd><a href="https://dokieli.github.io/application-capability/" rel="odrl:target">https://dokieli.github.io/application-capability/</a></dd>
<dt>Permission</dt>
<dd>
<dl id="document-permission" rel="odrl:permission" resource="#document-permission" typeof="odrl:Permission">
<dt>Assigner</dt>
<dd><a href="https://www.w3.org/groups/cg/foo-bar-baz/" rel="odrl:assigner">W3C Foo Bar Baz Group</a></dd>
<dt>Action</dt>
<dd>
<ul rel="odrl:action">
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-aggregate" resource="odrl:aggregate">Aggregate</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-archive" resource="odrl:archive">Archive</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-concurrentUse" resource="odrl:concurrentUse">Concurrent Use</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-DerivativeWorks" resource="http://creativecommons.org/ns#DerivativeWorks">Derivative Works</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-derive" resource="odrl:derive">Derive</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-digitize" resource="odrl:digitize">Digitize</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-display" resource="odrl:display">Display</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-Distribution" resource="http://creativecommons.org/ns#Distribution">Distribution</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-index" resource="odrl:index">Index</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-inform" resource="odrl:inform">Inform</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-install" resource="odrl:install">Install</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-Notice" resource="http://creativecommons.org/ns#Notice">Notice</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-present" resource="odrl:present">Present</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-print" resource="odrl:print">Print</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-read" resource="odrl:read">Read</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-reproduce" resource="odrl:reproduce">Reproduce</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-Reproduction" resource="http://creativecommons.org/ns#Reproduction">Reproduction</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-stream" resource="odrl:stream">Stream</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-synchronize" resource="odrl:synchronize">Synchronize</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-textToSpeech" resource="odrl:textToSpeech">Text-to-speech</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-transform" resource="odrl:transform">Transform</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-translate" resource="odrl:translate">Translate</a></li>
</ul>
</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</details>
<p class="copyright" rel="dcterms:rights" resource="#document-rights"><span property="dcterms:description"><a href="https://www.w3.org/policies/#copyright">Copyright</a> © 2024–9999 the Contributors to Application Capability, Version 0.3.1415, published by the <a href="https://www.w3.org/groups/cg/foo-bar-baz/">Foo Bar Baz Group</a> under the <a about="" href="https://www.w3.org/community/about/agreements/cla/" rel="schema:license">W3C Community Contributor License Agreement (CLA)</a>. A human-readable <a href="https://www.w3.org/community/about/agreements/cla-deed/">summary</a> is available. All code snippets are in the public domain, <a about="" href="https://creativecommons.org/public-domain/cc0/" rel="schema:license">CC0</a>.</span></p>
<hr title="Separator for header" />
</div>
<div datatype="rdf:HTML" id="content" property="schema:description">
<section id="abstract">
<h2>Abstract</h2>
<div datatype="rdf:HTML" property="schema:abstract">
<p>Application Capability (<abbr title="Application Capability">AC</abbr>) defines a structured description of an application's affordances: the actions it can perform, how to invoke them, and what it requires from the environment to function. Consumers, including servers, <a href="https://www.w3.org/TR/user-agents/">user agents</a>, and applications, can discover and process these descriptions to make informed decisions about accessing, presenting, and interacting with resources.</p>
</div>
</section>
<section id="sotd" inlist="" rel="schema:hasPart" resource="#sotd">
<h2 property="schema:name">Status of This Document</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>This report was published by the <a href="https://www.w3.org/groups/cg/foo-bar-baz/">Foo Bar Baz Group</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="https://www.w3.org/community/">W3C Community and Business Groups</a>.</p>
</div>
</section>
<nav id="toc">
<h2>Table of Contents</h2>
<div>
<ol class="toc">
<li class="tocline"><a class="tocxref" href="#abstract"><bdi class="secno"></bdi> <span>Abstract</span></a></li>
<li class="tocline"><a class="tocxref" href="#sotd"><bdi class="secno"></bdi> <span>Status of This Document</span></a></li>
<li class="tocline">
<p><a class="tocxref" href="#explainer"><bdi class="secno">1.</bdi> <span>Explainer</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#user-facing-problem"><bdi class="secno">1.1</bdi> <span>User-Facing Problem</span></a></li>
<li class="tocline"><a class="tocxref" href="#goals"><bdi class="secno">1.2</bdi> <span>Goals</span></a></li>
<li class="tocline"><a class="tocxref" href="#non-goals"><bdi class="secno">1.3</bdi> <span>Non-Goals</span></a></li>
<li class="tocline"><a class="tocxref" href="#proposed-approach"><bdi class="secno">1.4</bdi> <span>Proposed Approach</span></a></li>
<li class="tocline"><a class="tocxref" href="#alternatives-considered"><bdi class="secno">1.5</bdi> <span>Alternatives Considered</span></a></li>
<li class="tocline"><a class="tocxref" href="#stakeholder-feedback"><bdi class="secno">1.6</bdi> <span>Stakeholder Feedback</span></a></li>
</ol>
</li>
<li class="tocline">
<p><a class="tocxref" href="#introduction"><bdi class="secno">2.</bdi> <span>Introduction</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#terminology"><bdi class="secno">2.1</bdi> <span>Terminology</span></a></li>
<li class="tocline"><a class="tocxref" href="#namespaces"><bdi class="secno">2.2</bdi> <span>Namespaces</span></a></li>
<li class="tocline"><a class="tocxref" href="#syntax"><bdi class="secno">2.3</bdi> <span>Syntax</span></a></li>
</ol>
</li>
<li class="tocline">
<p><a class="tocxref" href="#conformance"><bdi class="secno">3.</bdi> <span>Conformance</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#normative-and-informative-content"><bdi class="secno">3.1</bdi> <span>Normative and Informative Content</span></a></li>
<li class="tocline"><a class="tocxref" href="#specification-category"><bdi class="secno">3.2</bdi> <span>Specification Category</span></a></li>
<li class="tocline"><a class="tocxref" href="#classes-of-products"><bdi class="secno">3.3</bdi> <span>Classes of Products</span></a></li>
<li class="tocline"><a class="tocxref" href="#interoperability"><bdi class="secno">3.4</bdi> <span>Interoperability</span></a></li>
<li class="tocline"><a class="tocxref" href="#subdivisions"><bdi class="secno">3.5</bdi> <span>Subdivisions</span></a></li>
</ol>
</li>
<li class="tocline"><a class="tocxref" href="#discovery"><bdi class="secno">4.</bdi> <span>Discovery</span></a></li>
<li class="tocline">
<p><a class="tocxref" href="#data-model"><bdi class="secno">5.</bdi> <span>Data Model</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#capability-description"><bdi class="secno">5.1</bdi> <span>Capability Description</span></a></li>
<li class="tocline"><a class="tocxref" href="#capability"><bdi class="secno">5.2</bdi> <span>Capability</span></a></li>
<li class="tocline">
<p><a class="tocxref" href="#invocation"><bdi class="secno">5.3</bdi> <span>Invocation</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#uri-template-invocation"><bdi class="secno">5.3.1</bdi> <span>URI Template Invocation</span></a></li>
</ol>
</li>
<li class="tocline"><a class="tocxref" href="#invocation-properties"><bdi class="secno">5.4</bdi> <span>Invocation Properties</span></a></li>
<li class="tocline"><a class="tocxref" href="#requirement"><bdi class="secno">5.5</bdi> <span>Requirement</span></a></li>
<li class="tocline"><a class="tocxref" href="#policy"><bdi class="secno">5.6</bdi> <span>Policy</span></a></li>
<li class="tocline"><a class="tocxref" href="#embedded-descriptions"><bdi class="secno">5.7</bdi> <span>Embedded Descriptions</span></a></li>
</ol>
</li>
<li class="tocline">
<p><a class="tocxref" href="#notifications"><bdi class="secno">6.</bdi> <span>Notifications</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#request-notification"><bdi class="secno">6.1</bdi> <span>Request Notification</span></a></li>
<li class="tocline"><a class="tocxref" href="#requirements-review"><bdi class="secno">6.2</bdi> <span>Requirements Review</span></a></li>
<li class="tocline"><a class="tocxref" href="#access-request"><bdi class="secno">6.3</bdi> <span>Access Request</span></a></li>
<li class="tocline"><a class="tocxref" href="#inbox"><bdi class="secno">6.4</bdi> <span>Inbox</span></a></li>
</ol>
</li>
<li class="tocline">
<p><a class="tocxref" href="#extensions"><bdi class="secno">7.</bdi> <span>Extensions</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#invocation-extension"><bdi class="secno">7.1</bdi> <span>Invocation Extension</span></a></li>
<li class="tocline"><a class="tocxref" href="#requirement-extension"><bdi class="secno">7.2</bdi> <span>Requirement Extension</span></a></li>
</ol>
</li>
<li class="tocline">
<p><a class="tocxref" href="#considerations"><bdi class="secno">8.</bdi> <span>Considerations</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#application-considerations"><bdi class="secno">8.1</bdi> <span>Application Considerations</span></a></li>
<li class="tocline"><a class="tocxref" href="#security-considerations"><bdi class="secno">8.2</bdi> <span>Security Considerations</span></a></li>
<li class="tocline"><a class="tocxref" href="#privacy-considerations"><bdi class="secno">8.3</bdi> <span>Privacy Considerations</span></a></li>
<li class="tocline"><a class="tocxref" href="#threat-model"><bdi class="secno">8.4</bdi> <span>Threat Model</span></a></li>
<li class="tocline"><a class="tocxref" href="#security-privacy-review"><bdi class="secno">8.5</bdi> <span>Security and Privacy Review</span></a></li>
<li class="tocline"><a class="tocxref" href="#societal-impact-review"><bdi class="secno">8.6</bdi> <span>Societal Impact Review</span></a></li>
<li class="tocline"><a class="tocxref" href="#accessibility-considerations"><bdi class="secno">8.7</bdi> <span>Accessibility Considerations</span></a></li>
<li class="tocline"><a class="tocxref" href="#internationalization-considerations"><bdi class="secno">8.8</bdi> <span>Internationalization Considerations</span></a></li>
</ol>
</li>
<li class="tocline"><a class="tocxref" href="#changelog"><bdi class="secno">A.</bdi> <span>Changelog</span></a></li>
<li class="tocline"><a class="tocxref" href="#acknowledgements"><bdi class="secno">B.</bdi> <span>Acknowledgements</span></a></li>
<li class="tocline">
<p><a class="tocxref" href="#references"><bdi class="secno">C.</bdi> <span>References</span></a></p>
<ol>
<li class="tocline"><a class="tocxref" href="#normative-references"><bdi class="secno">C.1</bdi> <span>Normative References</span></a></li>
<li class="tocline"><a class="tocxref" href="#informative-references"><bdi class="secno">C.2</bdi> <span>Informative References</span></a></li>
</ol>
</li>
</ol>
</div>
</nav>
<section id="explainer" inlist="" rel="schema:hasPart" resource="#explainer">
<h2 property="schema:name">Explainer</h2>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<div class="note" id="explainer-temporary-section" inlist="" rel="schema:hasPart" resource="#explainer-temporary-section">
<h3 property="schema:name"><span>Note</span>: Temporary Section</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>This section summarises the proposal for early review, following W3C TAG's <cite><a href="https://w3ctag.github.io/explainer-explainer/" rel="cito:citesForInformation">Writing Effective Explainers</a></cite>. Discussion takes place in the <a href="https://github.com/dokieli/application-capability/issues">issue tracker</a>. It is intended for early designs and will be removed as the specification matures.</p>
</div>
</div>
<section id="user-facing-problem" inlist="" rel="schema:hasPart" resource="#user-facing-problem">
<h3 property="schema:name">User-Facing Problem</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>People choose which applications to use on their resources. When a resource is stored independently of applications, neither the person nor software acting on their behalf can reliably find out which applications can open, edit, annotate, transform, or search it. They also cannot learn what those applications require from the environment, or how to hand the resource over to them. This knowledge is either hard-coded per application or mediated by platform-specific stores and registries.</p>
<p>AI agents assisting users face the same problem. To act on a resource with an application, an agent needs a structured account of what the application can do and how to trigger it, without driving the human interface and without requiring the application to be loaded first.</p>
<p>The problem is also not specific to web applications. Desktop applications and Progressive Web Apps handle resources and register invocation handlers. Their capabilities are described in platform-specific manifests that other parties cannot discover or process uniformly.</p>
</div>
</section>
<section id="goals" inlist="" rel="schema:hasPart" resource="#goals">
<h3 property="schema:name">Goals</h3>
<div datatype="rdf:HTML" property="schema:description">
<ul>
<li>An <a href="#dfn-application">Application</a> publishes one authoritative, machine-readable description of its <a href="#dfn-capability">capabilities</a> and <a href="#requirement" rel="rdfs:seeAlso">requirements</a> at a dereferenceable IRI.</li>
<li>Any <a href="#Consumer">Consumer</a>, such as a server, web user agent, application, catalogue, or agent, discovers the description and matches capabilities to a resource and a task.</li>
<li>A Consumer constructs an <a href="#dfn-invocation">invocation</a> IRI from a declared URI Template, so that a user can act on a resource with an application of their choice.</li>
<li>A server reviews an application's declared requirements, such as Content Security Policy directives, and makes informed authorisation decisions.</li>
<li>Human-facing and machine-facing use share one declaration. An agent selects a capability from the same description a catalogue or user agent presents to a person, so the two surfaces cannot drift apart.</li>
<li>The description is independent of how the application is built or deployed. Web applications, Progressive Web Apps, and desktop applications can publish or embed descriptions.</li>
<li>All of the above works without central registries or prior coordination between the parties.</li>
</ul>
</div>
</section>
<section id="non-goals" inlist="" rel="schema:hasPart" resource="#non-goals">
<h3 property="schema:name">Non-Goals</h3>
<div datatype="rdf:HTML" property="schema:description">
<ul>
<li>Script-level tool calling between an agent and a loaded application.</li>
<li>Defining or replacing web user agent permission models, Content Security Policy, or access control enforcement.</li>
<li>Describing user-activated operations or UI events within a running application.</li>
<li>Operating a registry of applications. Catalogues can be built from published descriptions.</li>
<li>Authentication. For example, the <a href="#variable-login"><code>login</code></a> invocation property is a hint about who to authenticate as, and the application remains responsible for authenticating the user.</li>
</ul>
</div>
</section>
<section id="proposed-approach" inlist="" rel="schema:hasPart" resource="#proposed-approach">
<h3 property="schema:name">Proposed Approach</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>An application publishes an <a href="#dfn-application-capability-description">Application Capability Description</a>, a JSON-LD document discoverable from the application IRI (see <a href="#discovery" rel="rdfs:seeAlso">Discovery</a>). The description declares <a href="#capability" rel="rdfs:seeAlso">Capabilities</a>, the actions the application can perform together with their matching criteria. Each capability links to <a href="#invocation" rel="rdfs:seeAlso">Invocations</a>. An invocation is typically a URI Template whose variables are bound to properties with defined semantics (see <a href="#invocation-properties" rel="rdfs:seeAlso">Invocation Properties</a>). The description also declares <a href="#requirement" rel="rdfs:seeAlso">Requirements</a>, such as Content Security Policy directives annotated with their purpose. It can further declare <a href="#policy" rel="rdfs:seeAlso">Policies</a> about the application's own conduct. <a href="#notifications" rel="rdfs:seeAlso">Notifications</a> let the application's needs be reviewed by the server hosting a resource. A description can also be embedded in host formats so that existing application metadata can carry it. Examples include a Web Application Manifest and a Web Extension manifest (see <a href="#embedded-descriptions" rel="rdfs:seeAlso">Embedded Descriptions</a>).</p>
<figure class="example listing" id="explainer-example" rel="schema:hasPart" resource="#explainer-example">
<figcaption property="schema:name"><span>Example</span>: <span>A minimal capability description. The application displays a resource supplied via the <code>open</code> variable. A Consumer invoking it with <code>open = https://data.example/article</code> navigates to <code>https://app.example/#open=https%3A%2F%2Fdata.example%2Farticle</code>.</span></figcaption>
<pre property="schema:description"><code>{
"@context": "https://www.w3.org/ns/ac/v1rc1",
"id": "https://app.example/",
"capability": {
"id": "#capability-open",
"type": "Capability",
"action": "http://www.w3.org/ns/odrl/2/display",
"invocation": {
"id": "#invoke-open",
"type": "UriTemplateInvocation",
"template": "#open={open}",
"mapping": [{ "variable": "open", "property": "https://www.w3.org/ns/ac#open" }]
}
}
}</code></pre>
</figure>
</div>
</section>
<section id="alternatives-considered" inlist="" rel="schema:hasPart" resource="#alternatives-considered">
<h3 property="schema:name">Alternatives Considered</h3>
<div datatype="rdf:HTML" property="schema:description">
<ul>
<li><cite>Web Application Manifest</cite> is scoped to installed applications mediated by the browser or operating system, not to applications acting on third-party resources.</li>
<li><cite>registerProtocolHandler</cite> requires prior browser registration and named schemes rather than arbitrary <code>https:</code> IRIs.</li>
<li><cite>Hydra Core Vocabulary</cite> describes HTTP API operations. This specification reuses its template and mapping terms by aliasing and subclassing, and adds capabilities, requirements, policies, and notifications.</li>
<li><cite>WebMCP</cite> registers script-defined tools imperatively and requires the application to be loaded in the browser.</li>
</ul>
<p>The <a href="#introduction" rel="rdfs:seeAlso">Introduction</a> lists the related efforts in full.</p>
</div>
</section>
<section id="stakeholder-feedback" inlist="" rel="schema:hasPart" resource="#stakeholder-feedback">
<h3 property="schema:name">Stakeholder Feedback</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><cite><a href="https://dokie.li/" rel="rdfs:seeAlso">dokieli</a></cite>, a clientside editor for decentralised article publishing, annotations, and social interactions, implements features across this specification. It has a capability description in JSON-LD (<code>curl -H'Accept: application/ld+json' https://dokie.li/</code>) and in <a href="https://dokie.li/#capabilities">HTML+RDFa</a>. An independent <cite><a href="https://application-capability-validator.mpeters.dev/" rel="rdfs:seeAlso">Application Capability validator</a></cite> checks a page's capability description against a SHACL shape for the vocabulary. Other implementers have expressed interest. Feedback from communities working on agent and application interoperability is particularly welcome. <a href="#application-considerations" rel="rdfs:seeAlso">Application</a>, <a href="#security-considerations" rel="rdfs:seeAlso">Security</a>, <a href="#privacy-considerations" rel="rdfs:seeAlso">Privacy</a>, <a href="#accessibility-considerations" rel="rdfs:seeAlso">Accessibility</a>, and <a href="#internationalization-considerations" rel="rdfs:seeAlso">Internationalisation</a> are addressed in <a href="#considerations" rel="rdfs:seeAlso">Considerations</a>. These include a <a href="#threat-model" rel="rdfs:seeAlso">Threat Model</a> and the completed <a href="#security-privacy-review" rel="rdfs:seeAlso">Security and Privacy Review</a> and <a href="#societal-impact-review" rel="rdfs:seeAlso">Societal Impact Review</a>.</p>
</div>
</section>
</div>
</section>
<section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction">
<h2 property="schema:name">Introduction</h2>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<p>Web applications increasingly operate in decentralised environments where resources are stored and served independently of the applications that consume them. A server hosting a resource has no prior knowledge of which applications a user wishes to use to interact with in different ways. Applications and tools such as resource managers, catalogues, and authorisation agents face the same problem: no reliable mechanism exists to discover what an application supports, what resource types it handles, or what web user agent permissions it requires.</p>
<p>This specification addresses that gap by defining a structured description of an application's capabilities and requirements. An <dfn id="dfn-application-capability-description">Application Capability Description</dfn> allows an application to declare, at a discoverable location, the following kinds of information:</p>
<ul>
<li>The media types, classes of resources, or shape of resources it can handle.</li>
<li>The actions it can perform on those resources, expressed in terms of established action vocabularies.</li>
<li>The invocation patterns used to trigger the application, such as a <cite>URI Template</cite> for opening a resource.</li>
<li>The web user agent level permissions and <cite>Content Security Policy</cite> directives it requires, so that server operators can make informed decisions about authorisation.</li>
<li>Descriptive information such as name, description, homepage, and repository, together with an inbox for receiving notifications about the outcome of a requirements review.</li>
</ul>
<p>This specification is informed by, but distinct from, the following related efforts:</p>
<ul>
<li><cite><a href="https://w3c.github.io/manifest/">Web Application Manifest</a></cite> defines a JSON-based manifest for installed web apps, primarily for Progressive Web Applications (PWA) use cases. The <code>file_handlers</code> member, defined in <cite><a href="https://wicg.github.io/manifest-incubations/">Manifest Incubations</a></cite>, declares media-type handling scoped to installed applications mediated by the browser or operating system.</li>
<li><cite><a href="https://w3c.github.io/webappsec-csp/">Content Security Policy Level 3</a></cite> defines the CSP header mechanism that servers use to restrict resource loading.</li>
<li><cite><a href="https://w3c.github.io/permissions/">Permissions</a></cite> and <cite><a href="https://w3c.github.io/webappsec-permissions-policy/">Permissions Policy</a></cite> define browser permission models.</li>
<li><cite><a href="https://w3c.github.io/dpv/dpv/">Data Privacy Vocabulary (DPV)</a></cite> provides vocabulary for expressing data processing purposes and policies.</li>
<li><cite><a href="http://usefulinc.com/ns/doap">Description of a Project (DOAP)</a></cite> provides vocabulary for describing software projects.</li>
<li><cite><a href="https://www.hydra-cg.com/spec/latest/core/">Hydra Core Vocabulary</a></cite> describes HTTP API operations and IRI templates in RDF.</li>
<li><cite><a href="https://www.w3.org/TR/wot-architecture11/">Web of Things (WoT) Architecture</a></cite> defines a self-description model for network-connected entities, describing interaction affordances of the entity itself. This specification describes applications that act on third-party resources and negotiate host-origin Content Security Policy.</li>
<li><cite><a href="https://webmachinelearning.github.io/webmcp/">WebMCP</a></cite> proposes an API for a web page to register script-defined tools that agents can call while the page is loaded in the browser. This specification declares capabilities at a dereferenceable IRI, so Consumers, including agents, can discover them without loading the application and invoke them by navigation.</li>
<li><cite><a href="https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers">registerProtocolHandler</a></cite> (HTML) allows a web application to register as a handler for a custom URL scheme, enabling scheme-based invocation. It requires prior user-mediated browser registration and is scoped to named schemes rather than arbitrary <code>https:</code> IRIs, making it unsuitable as a general mechanism for invoking applications against HTTP resources.</li>
<li><cite><a href="https://www.w3.org/TR/service-workers/">Service Workers</a></cite> can intercept fetch requests before they reach the network, allowing query-string parameters to remain client-side and avoiding server disclosure. This requires the service worker to be registered in advance, introducing a bootstrapping dependency that general-purpose invocation cannot rely on.</li>
</ul>
<p>Where terms from these vocabularies are appropriate, this specification reuses or references them.</p>
<p>Use cases:</p>
<ul id="use-cases">
<li>Resource owner wants to set application-specific content security policies for servers so that users can bring their own applications to hosted resources without the browser blocking them, and without the server issuing overly permissive blanket policies.</li>
<li>End-user wants to use a specific application based on its affordances so that they can choose among applications whose declared actions match their intent, without hardcoded file associations.</li>
<li>Application developer wants their application's entry in catalogues to update automatically, by publishing one authoritative capability description that catalogues re-fetch, instead of submitting updates to each catalogue manually.</li>
</ul>
<p>This specification is intended for:</p>
<ul about="" rel="schema:audience">
<li><a href="http://data.europa.eu/esco/occupation/a7c1d23d-aeca-4bee-9a08-5993ed98b135">Server and storage operators</a> that want to make security and privacy-relevant decisions about which applications can access resources they serve, and to understand the permissions those applications declare they need.</li>
<li><a href="http://data.europa.eu/esco/occupation/c40a2919-48a9-40ea-b506-1f34f693496d">Application developers</a> that want to produce or consume structured capability descriptions from their applications so that they can be discovered and invoked by other consumers.</li>
</ul>
<section id="terminology" inlist="" rel="schema:hasPart" resource="#terminology" typeof="skos:ConceptScheme">
<h3 property="schema:name skos:prefLabel">Terminology</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<p property="skos:definition">The Application Capability specification defines the following terms. These terms are referenced throughout this specification.</p>
<dl rel="skos:hasTopConcept">
<dt about="#dfn-application" property="skos:prefLabel" typeof="skos:Concept"><dfn id="dfn-application">Application</dfn></dt>
<dd about="#dfn-application" property="skos:definition">A web application that operates on resources identified by IRIs. An application can be deployed at a fixed origin, embedded in markup-based host languages, or as a <cite>Web Extension</cite>. An application could act as a <a href="#dfn-sender" rel="rdfs:seeAlso">Sender</a>, a <a href="#dfn-consumer" rel="rdfs:seeAlso">Consumer</a>, or both.</dd>
<dt about="#dfn-sender" property="skos:prefLabel" typeof="skos:Concept"><dfn id="dfn-sender">Sender</dfn></dt>
<dd about="#dfn-sender"><span property="skos:definition">An implementation that publishes and, where applicable, delivers an Application Capability Description to a <a href="#dfn-receiver" rel="rdfs:seeAlso">Receiver</a>. Typically an <a href="#dfn-application" rel="rdfs:seeAlso">Application</a> making its identity, capabilities, and requirements known.</span> See also <a href="#Sender" rel="skos:closeMatch">Sender</a> in <cite>Classes of Products</cite>.</dd>
<dt about="#dfn-receiver" property="skos:prefLabel" typeof="skos:Concept"><dfn id="dfn-receiver">Receiver</dfn></dt>
<dd about="#dfn-receiver"><span property="skos:definition">An implementation that accepts and processes capability descriptions or notifications referencing them. Typically an HTTP server that hosts resources, hosts an inbox, reviews declared requirements, and serves Content Security Policy headers accordingly to a <a href="#dfn-sender" rel="rdfs:seeAlso">Sender</a> or a <a href="#dfn-consumer" rel="rdfs:seeAlso">Consumer</a>.</span> See also <a href="#Receiver" rel="skos:closeMatch">Receiver</a> in <cite>Classes of Products</cite>.</dd>
<dt about="#dfn-consumer" property="skos:prefLabel" typeof="skos:Concept"><dfn id="dfn-consumer">Consumer</dfn></dt>
<dd about="#dfn-consumer"><span property="skos:definition">An implementation that reads and processes an Application Capability Description, obtained directly from the <a href="#dfn-application" rel="rdfs:seeAlso">Application</a>'s IRI or from a <a href="#dfn-receiver" rel="rdfs:seeAlso">Receiver</a>, in order to discover capabilities, prepare invocations, or inform authorisation decisions.</span> See also <a href="#Consumer" rel="skos:closeMatch">Consumer</a> in <cite>Classes of Products</cite>.</dd>
<dt about="#dfn-capability" property="skos:prefLabel" typeof="skos:Concept"><dfn id="dfn-capability">Capability</dfn></dt>
<dd about="#dfn-capability"><span property="skos:definition">A declared affordance of an <a href="#dfn-application" rel="rdfs:seeAlso">Application</a>: an action that can be triggered by an invocation.</span> See also <a href="#capability" rel="rdfs:seeAlso">Capability</a> in the <cite>Data Model</cite>.</dd>
<dt about="#dfn-invocation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="dfn-invocation">Invocation</dfn></dt>
<dd about="#dfn-invocation"><span property="skos:definition">The act of triggering an <a href="#dfn-application" rel="rdfs:seeAlso">Application</a> to perform processes, for example by navigating to a URI constructed from a URI Template. For invocations based on URI Templates, an invocation covers only the URL-loading step. Subsequent user-activated operations or UI events within the application are out of scope, even though the capabilities do express these affordances.</span> See also <a href="#invocation" rel="rdfs:seeAlso">Invocation</a> in the <cite>Data Model</cite>.</dd>
</dl>
</div>
</section>
<section id="namespaces" inlist="" rel="schema:hasPart" resource="#namespaces">
<h3 property="schema:name">Namespaces</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>In prose, a term defined in the JSON-LD context is referred to by its term name (for example, <code>Capability</code>), and any other IRI is written using the compact IRI (CURIE) convention [<cite><a class="bibref" href="#bib-curie">CURIE</a></cite>], in which a prefix abbreviates a namespace IRI (for example, <code>odrl:Policy</code> denotes <code>http://www.w3.org/ns/odrl/2/Policy</code>). The following prefixes and namespaces are used in this specification.</p>
<table id="prefixes-namespaces">
<caption>Prefixes and Namespaces</caption>
<thead>
<tr>
<th>Prefix</th>
<th>Namespace</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>ac</code></td>
<td>https://www.w3.org/ns/ac#</td>
<td>Application Capability (this specification)</td>
</tr>
<tr>
<td><code>as</code></td>
<td>https://www.w3.org/ns/activitystreams#</td>
<td>[<cite><a class="bibref" href="#bib-activitystreams-vocabulary">Activity Vocabulary</a></cite>]</td>
</tr>
<tr>
<td><code>dcterms</code></td>
<td>http://purl.org/dc/terms/</td>
<td>[<cite><a class="bibref" href="#bib-dc-terms">DC-TERMS</a></cite>]</td>
</tr>
<tr>
<td><code>doap</code></td>
<td>http://usefulinc.com/ns/doap#</td>
<td>Description of a Project</td>
</tr>
<tr>
<td><code>dpv</code></td>
<td>https://w3id.org/dpv#</td>
<td>[<cite><a class="bibref" href="#bib-dpv">Data Privacy Vocabulary</a></cite>]</td>
</tr>
<tr>
<td><code>hydra</code></td>
<td>http://www.w3.org/ns/hydra/core#</td>
<td>[<cite><a class="bibref" href="#bib-hydra">Hydra Core Vocabulary</a></cite>]</td>
</tr>
<tr>
<td><code>ldp</code></td>
<td>http://www.w3.org/ns/ldp#</td>
<td>[<cite><a class="bibref" href="#bib-ldp">Linked Data Platform</a></cite>]</td>
</tr>
<tr>
<td><code>oa</code></td>
<td>http://www.w3.org/ns/oa#</td>
<td>[<cite><a class="bibref" href="#bib-annotation-vocab">Web Annotation Vocabulary</a></cite>]</td>
</tr>
<tr>
<td><code>odrl</code></td>
<td>http://www.w3.org/ns/odrl/2/</td>
<td>[<cite><a class="bibref" href="#bib-odrl-vocab">ODRL Vocabulary & Expression 2.2</a></cite>]</td>
</tr>
<tr>
<td><code>rdf</code></td>
<td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
<td>[<cite><a class="bibref" href="#bib-rdf-schema">rdf-schema</a></cite>]</td>
</tr>
<tr>
<td><code>rdfs</code></td>
<td>http://www.w3.org/2000/01/rdf-schema#</td>
<td>[<cite><a class="bibref" href="#bib-rdf-schema">rdf-schema</a></cite>]</td>
</tr>
</tbody>
</table>
</div>
</section>
<section id="syntax" inlist="" rel="schema:hasPart" resource="#syntax">
<h3 property="schema:name">Syntax</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>This specification uses JSON-LD [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>] as the preferred data format. The JSON-LD context for the current version is <code>https://www.w3.org/ns/ac/v1rc1</code>. Content negotiation uses <code>https://www.w3.org/ns/ac</code> as the value of the <code>profile</code> parameter, a version-independent identifier for an application capability description.</p>
<div class="note" id="jsonld-context-temporary-inclusion" inlist="" rel="schema:hasPart" resource="#jsonld-context-temporary-inclusion">
<h4 property="schema:name"><span>Note</span>: Temporary Inclusion</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>The JSON-LD context and the vocabulary outlined in this section are temporarily included here. Once the JSON-LD context document and the vocabulary are published, they will be the normative references. The context is versioned and immutable; <code>https://www.w3.org/ns/ac/v1rc1</code> is a release candidate for early deployments, and the final release will be published at <code>https://www.w3.org/ns/ac/v1</code>.</p>
</div>
</div>
<figure class="listing" id="jsonld-context" rel="schema:hasPart" resource="#jsonld-context">
<figcaption property="schema:name">JSON-LD context (<code>https://www.w3.org/ns/ac/v1rc1</code>)</figcaption>
<pre><code datatype="rdf:JSON" property="schema:description">{
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"Accept": "https://www.w3.org/ns/activitystreams#Accept",
"accept": "https://www.w3.org/ns/ac#accept",
"action": {"@id": "https://www.w3.org/ns/ac#action", "@type": "@id"},
"actor": {"@id": "https://www.w3.org/ns/activitystreams#actor", "@type": "@id"},
"browserPermission": "https://www.w3.org/ns/ac#browserPermission",
"Capability": "https://www.w3.org/ns/ac#Capability",
"capability": {"@id": "https://www.w3.org/ns/ac#capability", "@type": "@id"},
"cspDirective": "https://www.w3.org/ns/ac#cspDirective",
"destination": {"@id": "https://www.w3.org/ns/ac#destination", "@type": "@id"},
"hasPurpose": {"@id": "https://w3id.org/dpv#hasPurpose", "@type": "@id"},
"inbox": {"@id": "http://www.w3.org/ns/ldp#inbox", "@type": "@id"},
"Invocation": "https://www.w3.org/ns/ac#Invocation",
"invocation": {"@id": "https://www.w3.org/ns/ac#invocation", "@type": "@id"},
"issuedPolicy": {"@id": "http://www.w3.org/ns/odrl/2/issuedPolicy", "@type": "@id"},
"login": {"@id": "https://www.w3.org/ns/ac#login", "@type": "@id"},
"mapping": "http://www.w3.org/ns/hydra/core#mapping",
"object": {"@id": "https://www.w3.org/ns/activitystreams#object", "@type": "@id"},
"open": {"@id": "https://www.w3.org/ns/ac#open", "@type": "@id"},
"output": "https://www.w3.org/ns/ac#output",
"property": {"@id": "http://www.w3.org/ns/hydra/core#property", "@type": "@id"},
"proxy": {"@id": "https://www.w3.org/ns/ac#proxy", "@type": "@id"},
"Reject": "https://www.w3.org/ns/activitystreams#Reject",
"Request": "https://www.w3.org/ns/ac#Request",
"Requirement": "https://www.w3.org/ns/ac#Requirement",
"requirement": {"@id": "https://www.w3.org/ns/ac#requirement", "@type": "@id"},
"resourceType": {"@id": "https://www.w3.org/ns/ac#resourceType", "@type": "@id"},
"search": "https://www.w3.org/ns/ac#search",
"selector": {"@id": "http://www.w3.org/ns/oa#hasSelector", "@type": "@id"},
"state": {"@id": "http://www.w3.org/ns/oa#hasState", "@type": "@id"},
"shape": {"@id": "https://www.w3.org/ns/ac#shape", "@type": "@id"},
"template": "http://www.w3.org/ns/hydra/core#template",
"UriTemplateInvocation": "https://www.w3.org/ns/ac#UriTemplateInvocation",
"variable": "http://www.w3.org/ns/hydra/core#variable"
}
}</code></pre>
</figure>
<p id="combining-jsonld-contexts">When this context is combined with other JSON-LD contexts, for example ActivityStreams in <a href="#request-notification" rel="rdfs:seeAlso">Request Notifications</a>, it is listed last so that its term definitions apply, in addition to being protected.</p>
<p id="typing-the-application">This context does not define a term for typing the application itself. A capability description subject can carry any type from its host vocabulary (for example <code>as:Application</code>, an OAuth client, a <code>doap:Project</code>, or a Web of Things Thing) or none at all. See <a href="#capability-description" rel="rdfs:seeAlso">Capability Description</a>.</p>
<p>The <code>ac</code> vocabulary defines the following classes and properties. Terms mapped to other vocabularies, such as ActivityStreams, Hydra, Linked Data Platform, ODRL, Web Annotation, and Data Privacy Vocabulary, retain the semantics of their defining specifications.</p>
<table id="classes">
<caption>Classes</caption>
<thead>
<tr>
<th>Term</th>
<th>IRI</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>Accept</code>, <code>Reject</code></td>
<td><code>as:Accept</code>, <code>as:Reject</code></td>
<td>Outcome notification types (Activity Vocabulary).</td>
</tr>
<tr>
<td>(none)</td>
<td><code>ac:Application</code></td>
<td>A web application that operates on resources identified by IRIs. Not aliased in the context: a capability description subject can use this class, a host vocabulary's type, or none at all.</td>
</tr>
<tr>
<td><code>Capability</code></td>
<td><code>ac:Capability</code></td>
<td>A declared affordance of an application: an action that can be triggered by an invocation. See <a href="#capability" rel="rdfs:seeAlso">Capability</a>.</td>
</tr>
<tr>
<td><code>Invocation</code></td>
<td><code>ac:Invocation</code></td>
<td>An abstract class describing one mechanism by which a capability is triggered. See <a href="#invocation" rel="rdfs:seeAlso">Invocation</a>.</td>
</tr>
<tr>
<td><code>Request</code></td>
<td><code>ac:Request</code></td>
<td>A notification asking a Receiver to review information concerning an application and act on it. See <a href="#request-notification" rel="rdfs:seeAlso">Request Notification</a>.</td>
</tr>
<tr>
<td><code>Requirement</code></td>
<td><code>ac:Requirement</code></td>
<td>A declaration of something the application needs from its environment. See <a href="#requirement" rel="rdfs:seeAlso">Requirement</a>.</td>
</tr>
<tr>
<td><code>UriTemplateInvocation</code></td>
<td><code>ac:UriTemplateInvocation</code></td>
<td>An Invocation by navigation to an IRI constructed from a URI Template, a subclass of <code>hydra:IriTemplate</code>. See <a href="#uri-template-invocation" rel="rdfs:seeAlso">URI Template Invocation</a>.</td>
</tr>
</tbody>
</table>
<table id="properties">
<caption>Properties</caption>
<thead>
<tr>
<th>Term</th>
<th>IRI</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>accept</code></td>
<td><code>ac:accept</code></td>
<td>Media types a capability accepts as input.</td>
</tr>
<tr>
<td><code>action</code></td>
<td><code>ac:action</code></td>
<td>The action a capability affords, preferably from a controlled and shared vocabulary.</td>
</tr>
<tr>
<td><code>actor</code>, <code>object</code>, <code>summary</code></td>
<td><code>as:actor</code>, <code>as:object</code>, <code>as:summary</code></td>
<td>Properties used in <a href="#request-notification" rel="rdfs:seeAlso">Request Notifications</a> (Activity Vocabulary).</td>
</tr>
<tr>
<td><code>browserPermission</code></td>
<td><code>ac:browserPermission</code></td>
<td>A browser permission name the application could request at runtime.</td>
</tr>
<tr>
<td><code>capability</code></td>
<td><code>ac:capability</code></td>
<td>Links an application to one or more <a href="#capability" rel="rdfs:seeAlso">Capability</a> declarations.</td>
</tr>
<tr>
<td><code>cspDirective</code></td>
<td><code>ac:cspDirective</code></td>
<td>A CSP directive the host server ought to include with responses of resources the application creates, modifies, or opens.</td>
</tr>
<tr>
<td><code>destination</code></td>
<td><code>ac:destination</code></td>
<td>The IRI to deliver or save the result of an action to.</td>
</tr>
<tr>
<td><code>hasPurpose</code></td>
<td><code>dpv:hasPurpose</code></td>
<td>Links to a DPV purpose class expressing why the application needs the declared permissions.</td>
</tr>
<tr>
<td><code>login</code>, <code>open</code>, <code>output</code>, <code>proxy</code>, <code>search</code></td>
<td><code>ac:login</code>, <code>ac:open</code>, <code>ac:output</code>, <code>ac:proxy</code>, <code>ac:search</code></td>
<td>Invocation properties parameterising the IRI used to invoke an application. See <a href="#invocation-properties" rel="rdfs:seeAlso">Invocation Properties</a>.</td>
</tr>
<tr>
<td><code>selector</code>, <code>state</code></td>
<td><code>oa:hasSelector</code>, <code>oa:hasState</code></td>
<td>Invocation properties identifying a segment and a version of the resource. See <a href="#invocation-properties" rel="rdfs:seeAlso">Invocation Properties</a>.</td>
</tr>
<tr>
<td><code>inbox</code></td>
<td><code>ldp:inbox</code></td>
<td>The IRI of a Linked Data Notifications inbox associated with the application.</td>
</tr>
<tr>
<td><code>invocation</code></td>
<td><code>ac:invocation</code></td>
<td>Links a capability to one or more <a href="#invocation" rel="rdfs:seeAlso">Invocations</a> describing how to trigger it.</td>
</tr>
<tr>
<td><code>issuedPolicy</code></td>
<td><code>odrl:issuedPolicy</code></td>
<td>Links an application, as a Party, to a <a href="#policy" rel="rdfs:seeAlso">Policy</a> it issues about its own conduct.</td>
</tr>
<tr>
<td><code>mapping</code></td>
<td><code>hydra:mapping</code></td>
<td>Mapping nodes pairing a template variable with its defining property.</td>
</tr>
<tr>
<td><code>output</code></td>
<td><code>ac:output</code></td>
<td>Media types of the result produced by a capability's action.</td>
</tr>
<tr>
<td><code>property</code></td>
<td><code>hydra:property</code></td>
<td>The property defining the semantics of a template variable.</td>
</tr>
<tr>
<td><code>requirement</code></td>
<td><code>ac:requirement</code></td>
<td>Links an application to one or more <a href="#requirement" rel="rdfs:seeAlso">Requirement</a> declarations.</td>
</tr>
<tr>
<td><code>resourceType</code></td>
<td><code>ac:resourceType</code></td>
<td>IRIs identifying the classes of resource a capability applies to.</td>
</tr>
<tr>
<td><code>shape</code></td>
<td><code>ac:shape</code></td>
<td>IRIs identifying shapes for a resource that a capability applies to.</td>
</tr>
<tr>
<td><code>template</code></td>
<td><code>hydra:template</code></td>
<td>A URI Template [<cite><a class="bibref" href="#bib-rfc6570">RFC6570</a></cite>] expressing the invocation-specific part of the IRI.</td>
</tr>
<tr>
<td><code>variable</code></td>
<td><code>hydra:variable</code></td>
<td>The string name of a variable as used in a template.</td>
</tr>
</tbody>
</table>
</div>
</section>
</div>
</section>
<section id="conformance" inlist="" rel="schema:hasPart" resource="#conformance">
<h2 property="schema:name">Conformance</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>This section describes the <span about="" rel="spec:conformance" resource="#conformance">conformance model of the Application Capability specification</span>.</p>
<section id="normative-and-informative-content" inlist="" rel="schema:hasPart" resource="#normative-and-informative-content">
<h3 property="schema:name">Normative and Informative Content</h3>
<div datatype="rdf:HTML" property="schema:description">
<p id="normative-informative-sections">All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.</p>
<p id="requirement-levels">The key words “<span rel="dcterms:subject" resource="spec:MUST">MUST</span>”, “<span rel="dcterms:subject" resource="spec:MUSTNOT">MUST NOT</span>”, “<span rel="dcterms:subject" resource="spec:SHOULD">SHOULD</span>”, and “<span rel="dcterms:subject" resource="spec:MAY">MAY</span>” are to be interpreted as described in <a href="https://www.rfc-editor.org/info/bcp14">BCP 14</a> [<cite><a class="bibref" href="#bib-rfc2119">RFC2119</a></cite>] [<cite><a class="bibref" href="#bib-rfc8174">RFC8174</a></cite>] when, and only when, they appear in all capitals, as shown here.</p>
<p id="advisement-levels">The key words "<span rel="dcterms:subject" resource="spec:StronglyEncouraged">strongly encouraged</span>", "<span rel="dcterms:subject" resource="spec:StronglyDiscouraged">strongly discouraged</span>", "<span rel="dcterms:subject" resource="spec:Encouraged">encouraged</span>", "<span rel="dcterms:subject" resource="spec:Discouraged">discouraged</span>", "<span rel="dcterms:subject" resource="spec:Can">can</span>", "<span rel="dcterms:subject" resource="spec:Cannot">cannot</span>", "<span rel="dcterms:subject" resource="spec:Could">could</span>", "<span rel="dcterms:subject" resource="spec:CouldNot">could not</span>", "<span rel="dcterms:subject" resource="spec:Might">might</span>", and "<span rel="dcterms:subject" resource="spec:MightNot">might not</span>" are used for non-normative content.</p>
</div>
</section>
<section id="specification-category" inlist="" rel="schema:hasPart spec:specificationCategory" resource="#specification-category" typeof="skos:ConceptScheme">
<h3 property="schema:name skos:prefLabel">Specification Category</h3>
<div datatype="rdf:HTML" property="schema:description">
<p property="skos:definition">The <span about="" rel="spec:specificationCategory" resource="#specification-category">Application Capability</span> specification identifies the following <cite><a href="https://www.w3.org/TR/spec-variability/#spec-cat" rel="dcterms:subject" resource="spec:SpecificationCategory">Specification Category</a></cite> to distinguish the types of conformance: <span rel="skos:hasTopConcept" resource="spec:ContentData">content/data</span> (the capability description format), <span rel="skos:hasTopConcept" resource="spec:NotationSyntax">notation/syntax</span> (the URI Template invocation syntax), and <span rel="skos:hasTopConcept" resource="spec:Protocol">protocol</span> (the discovery and notification interactions between Senders, Receivers, and Consumers).</p>
</div>
</section>
<section id="classes-of-products" inlist="" rel="schema:hasPart" resource="#classes-of-products" typeof="skos:ConceptScheme">
<h3 property="schema:name skos:prefLabel">Classes of Products</h3>
<div datatype="rdf:HTML" property="schema:description">
<p property="skos:definition">The <span about="" rel="spec:classesOfProducts" resource="#classes-of-products">Application Capability</span> specification identifies the following <cite><a href="https://www.w3.org/TR/qaframe-spec/#cop-def" rel="dcterms:subject" resource="spec:ClassesOfProducts">Classes of Products</a></cite> for conforming implementations.</p>
<p>A single implementation can fulfil more than one role simultaneously.</p>
<dl rel="skos:hasTopConcept">
<dt about="#CapabilityDescription" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:Content" typeof="skos:Concept"><dfn id="CapabilityDescription">Capability Description</dfn></dt>
<dd about="#CapabilityDescription" property="skos:definition">The structured document describing a web application's capabilities and requirements.</dd>
<dt about="#Receiver" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="Receiver">Receiver</dfn></dt>
<dd about="#Receiver" property="skos:definition">An implementation (typically a <cite>responding agent</cite> such as a server) that accepts HTTP requests to provide a representation of a <a href="#CapabilityDescription">Capability Description</a>. Receivers also accept notifications to their inbox about capability descriptions so that the needs of an application can be reviewed and processed, such as applying CSP headers or addressing authorisation needs.</dd>
<dt about="#Consumer" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:Consumer" typeof="skos:Concept"><dfn id="Consumer">Consumer</dfn></dt>
<dd about="#Consumer" property="skos:definition">An implementation that reads and processes a <a href="#CapabilityDescription">Capability Description</a> in order to discover application's capabilities and requirements, construct invocation instructions, or surface other application affordances.</dd>
<dt about="#Sender" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:ProducerOfContent" typeof="skos:Concept"><dfn id="Sender">Sender</dfn></dt>
<dd about="#Sender" property="skos:definition">An implementation that delivers a <a href="#CapabilityDescription">Capability Description</a> to a Receiver's inbox.</dd>
</dl>
</div>
</section>
<section id="interoperability" inlist="" rel="schema:hasPart" resource="#interoperability">
<h3 property="schema:name skos:prefLabel">Interoperability</h3>
<div datatype="rdf:HTML" property="schema:description">
<p property="skos:definition">In this specification, interoperability occurs between the <a href="#classes-of-products" rel="rdfs:seeAlso">Classes of Products</a> defined by this specification: <a href="#Consumer-CapabilityDescription" rel="skos:hasTopConcept">Consumer–CapabilityDescription</a>, <a href="#Consumer-Receiver" rel="skos:hasTopConcept">Consumer–Receiver</a>, and <a href="#Sender-Receiver" rel="skos:hasTopConcept">Sender–Receiver</a>.</p>
<dl>
<dt about="#Consumer-CapabilityDescription" property="skos:prefLabel" typeof="skos:Concept"><dfn id="Consumer-CapabilityDescription">Consumer–Capability Description interoperability</dfn></dt>
<dd about="#Consumer-CapabilityDescription" property="skos:definition">Interoperability of implementations for <a href="#Consumer" rel="rdfs:seeAlso">Consumer</a> and <a href="#CapabilityDescription" rel="rdfs:seeAlso">Capability Description</a> is tested by evaluating the description's conformance to the data model and processing of descriptions.</dd>
<dt about="#Consumer-Receiver" property="skos:prefLabel" typeof="skos:Concept"><dfn id="Consumer-Receiver">Consumer–Receiver interoperability</dfn></dt>
<dd about="#Consumer-Receiver" property="skos:definition">Interoperability of implementations for <a href="#Consumer" rel="rdfs:seeAlso">Consumer</a> and <a href="#Receiver" rel="rdfs:seeAlso">Receiver</a> is tested by evaluating an implementation's ability to request and respond to HTTP messages.</dd>
<dt about="#Sender-Receiver" property="skos:prefLabel" typeof="skos:Concept"><dfn id="Sender-Receiver">Sender–Receiver interoperability</dfn></dt>
<dd about="#Sender-Receiver" property="skos:definition">Interoperability of implementations for <a href="#Sender" rel="rdfs:seeAlso">Sender</a> and <a href="#Receiver" rel="rdfs:seeAlso">Receiver</a> is tested by evaluating an implementation's ability to request and respond to HTTP messages.</dd>
</dl>
</div>
</section>
<section id="subdivisions" inlist="" rel="schema:hasPart" resource="#subdivisions">
<h3 property="schema:name">Subdivisions</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>This document can be subdivided into the following <a href="https://www.w3.org/TR/spec-variability/#subdivision-module">modules</a>:</p>
<ul about="" rel="spec:module">
<li resource="#module-discovery-data-model" typeof="spec:ConformanceModule"><a href="#discovery" rel="schema:hasPart">Discovery</a> together with the <a href="#data-model" rel="schema:hasPart">Data Model</a></li>
<li resource="#module-notifications" typeof="spec:ConformanceModule"><a href="#notifications" rel="schema:hasPart">Notifications</a></li>
</ul>
</div>
</section>
</div>
</section>
<section id="discovery" inlist="" rel="schema:hasPart" resource="#discovery">
<h2 property="schema:name">Discovery</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>The starting point for discovery is a web resource containing a capability description. How the subject URI of an application is obtained is not constrained by this specification.</p>
<p>A <a href="#capability-description" rel="rdfs:seeAlso">capability description</a> is the set of statements this specification defines about an application, sharing the application's IRI as their subject. A <a href="#Consumer">Consumer</a> that obtains that IRI treats it as the subject of the capability description and dereferences it, directly or via redirect, requesting a format that carries the description, such as <code>application/ld+json</code>. In the case of a fragment URI, the Consumer fetches the document at the base IRI and locates the subject within it by matching the full URI. A <a href="#Consumer">Consumer</a> can obtain a capability description from a <a href="#Receiver">Receiver</a> that has accepted and stored it from a <a href="#Sender">Sender</a>.</p>
<p></p>
<figure class="example listing" id="description-resource-request-response" rel="schema:hasPart" resource="#description-resource-request-response">
<figcaption property="schema:name"><span>Example</span>: <span>Discovery of a capability description resource.</span></figcaption>
<pre property="schema:description"><code>GET https://app.example/</code>
<code>Accept: application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: application/ld+json</code></pre>
</figure>
</div>
</section>
<section id="data-model" inlist="" rel="schema:hasPart" resource="#data-model">
<h2 property="schema:name">Data Model</h2>
<div datatype="rdf:HTML" property="schema:description">
<section id="capability-description" inlist="" rel="schema:hasPart" resource="#capability-description">
<h3 property="schema:name">Capability Description</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>The following application-level properties are defined by this specification for describing an application.</p>
<dl>
<dt><dfn id="description-capability"><code>capability</code></dfn></dt>
<dd>Links the application to one or more <a href="#capability" rel="rdfs:seeAlso"><code>Capability</code></a> declarations.</dd>
<dt><dfn id="description-requirement"><code>requirement</code></dfn></dt>
<dd>Links the application to one or more <a href="#requirement" rel="rdfs:seeAlso"><code>Requirement</code></a> declarations.</dd>
<dt><dfn id="description-inbox"><code>inbox</code></dfn></dt>
<dd>The IRI of an inbox to which notifications concerning the application can be delivered, such as the outcome of a requirements review. Applications that wish to receive such notifications can publish this property [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</dd>
<dt><dfn id="description-issuedPolicy"><code>issuedPolicy</code></dfn></dt>
<dd>Links the application, as an <code>odrl:Party</code>, to a <a href="#policy" rel="rdfs:seeAlso">policy</a>, inline or referenced by IRI, it asserts about its own conduct, e.g., rules over data it processes or defaults it applies to resources it creates [<cite><a class="bibref" href="#bib-odrl-model">ODRL-MODEL</a></cite>]. Issuing a policy grants no privileges.</dd>
</dl>
<p id="capability-requirement-attachment">These properties can be attached to any resource identifying an application. The <code>Application</code> type is not required for conformance. Consumers process these properties by subject, consistent with <a href="#discovery" rel="rdfs:seeAlso">Discovery</a>, which targets the application as the subject of these statements. See <a href="#embedded-descriptions" rel="rdfs:seeAlso">Embedded Descriptions</a> for usage alongside other vocabularies and within non-RDF formats.</p>
<figure class="example listing" id="capability-description-example" rel="schema:hasPart" resource="#capability-description-example">
<figcaption property="schema:name"><span>Example</span>: <span>Application capability description in JSON-LD. One capability per action, referenced here by IRI. The type and descriptive properties come from host vocabularies (here ActivityStreams' <code>Application</code> and <code>name</code>) and are not required.</span></figcaption>
<pre property="schema:description"><code>{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://www.w3.org/ns/ac/v1rc1"
],
"id": "https://app.example/#i",
"type": "Application",
"name": "Example App",
"inbox": "https://app.example/inbox/",
"capability": [
"#capability-view",
"#capability-edit",
"#capability-transform-html"
],
"requirement": [
"#requirement-scripts",
"#requirement-styles",
"#requirement-connect",
"#requirement-notifications"
],
"issuedPolicy": "#policy-conduct"
}</code></pre>
</figure>