-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.txt
913 lines (721 loc) · 32.7 KB
/
index.txt
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
= Application-Level Profile Semantics =
Revision: 2012-10-29 (mca)
Some topics for conversation.
1. I would like to discuss the addition of a +parent+ element,
analogous to +child+. This would allow one ALPS document to
unilaterally extend another.
I used this heavily in my first draft of the ALPS version of Activity
Streams. When an extension element extended 'activity', I said that
its parent was the #activity object in another file. Similarly for
#object.
Then I decided to take a more laid-back, microformats-ish
approach. Now the extension elements can be used anywhere. I feel that
this is a better approach, because it means the elements are much more
reusable. But I think there's still be a case for #parent.
The main problem with this (apart from implementation difficulties) is
that the attributes look weird:
<element id="foo"
<parent href="http://other.doc/#bar" appears="MAY"
cardinality="many"/>
</element>
This makes it sound like a +foo+ may have zero, one or more parents,
each of which is a +bar+. When actually it's saying that a +foo+ may
appear zero, one, or many times within a +bar+.
2. Because of that, I would like to explore the possibility of
replacing +child+ and +parent+ with a generic +link+.
<element id="foo">
<link rel="parent" href="http://other.doc/#bar" appears="MAY"
cardinality="many"/>
</element>
This would make ALPS into a general hypermedia format. +appears+ and
cardinality would only make sense for +child+ and +parent+.
The disadvantage (it's a big disadvantage) is extra verbosity and lack
of clarity in the common case.
If you don't like this, what about allowing a general +link+ with
+rel+ as an extension mechanism.
3. A lot of semantic descriptors also make sense as link
relations. The "inventory" descriptor from the treasure hunt is
defined as a link relation, and as the name of the top-level tag you
find when you follow the link.
While working on the Activity Streams translation I discovered that
*most* semantic descriptors could be used as safe link
relations. For "event", "collection", "location", even "longitude", it
might make sense to either include the value inline or link to a
standalone resource whose representation provides the value.
I think the ALPS spec should say that a semantic descriptor can be
used as a safe link relation. If the name of a descriptor conflicts
with an IANA-registered link relation, the local name takes
precedence. (This is the only way to prevent a situation where
additions to IANA change the meaning of preexisting ALPS documents.)
<a href="foo" rel="event">
->
<span class="event">
...
</span>
Alternatively, we could say that a semantic descriptor applied to a
hypermedia link "types" the link.
<a href="foo" class="event" rel="somethingelse">
->
<span class="event">
...
</span>
But that seems to reinvent the work done by the link relation. And I
don't know if there's support in all our target representation formats
for applying semantic descriptors (as opposed to link relations) to
links.
4. There are two big difficulties with making an ALPS version of
Activity Streams.
4a. Every object is supposed to have an "objectType" attribute. For
each provided value for "objectType" (e.g. "event", "game"), I defined
a combination link relation/semantic descriptor. But there's no way
in ALPS to indicate that a certain semantic descriptor is expected to
be used as a value for "objectType".
To approximate this I got rid of objectType and mentioned in the
definition of "url" that any hypermedia control with descriptor "url"
should set its link relation to reflect the object type on the other
end.
<div class="object">"
<a class="url" href="http://www.example.com/events/44" rel="event">
Birthday party
</a>
</div>
"event" is not technically a relationship, but neither is "inventory".
But there's still no way of saying within ALPS that _those particular_
link relations are intended to be the partial range of "url"'s link
relation.
4b. Every activity has a "verb" associated with it which serves the
same purpose as objectType. It explains what kind of activity this
is. e.g. "consume", "checkin", "dislike".
I defined an unsafe link relation for every verb, but there's no way
in ALPS to explain that those link relations are intended to be the
partial range of the "verb" descriptor.
I don't think we should extend ALPS to deal with these two problems,
but does it make sense to define an Activity Streams-specific
extension?
<element id="checkin" type="unsafe verb">
<element id="game" type="safe descriptor objectType">
5. Given the prevalence of the collection pattern, it may make sense
to allow an ALPS document to hint that a given descriptor describes a
collection rather than a single object. We could do this e.g. by
defining "collection" as another type, a subtype of "descriptor".
<element id="vcalendar" type="collection" appears="MAY">
<description>
A calendar of events.
</description>
<child href="#event"/ cardinality="many">
</element>
I don't know if this feature would really be useful.
== Summary ==
This document describes a media type for defining application-level
semantic descriptions (similar to those defined by HTML microformats)
in a way that incorporates both human-readable documentation and
machine-readable instructions on applying semantic descriptions to
elements within application-agnostic media-type representations (such
as HTML, HAL, Collection+JSON, and Siren). This document also sets a
standard for creating and registering ALPS document identifers and
provides suggested conventions for applying ALPS descriptors to
existing media types.
This document registers two media-type identifiers with the IANA:
+application/vnd.alps+xml+ ("ALPS+XML") and
+application/vnd.alps+json+ ("ALPS+JSON").
== Simple Example ==
[TK]
== Motivation ==
When implementing a hypermedia client/server application using a
general media type (i.e. HTML, Atom, Collection+JSON, etc.), client
and server instances need to share application-specific information
such as data element names, link relation values, and state transfer
parameters. This information is directly related to the application
being implemented (i.e. accounting, contact management, etc.) rather
than the media type used in the representations.
Instead of creating (and registering) an entirely new media type (i.e.
+application/accounting+), representation authors can use an ALPS
"profile" to apply application-level semantic descriptions to elements
defined by the generic media type. This increases the specificity of
the representation without reducing the generality of the media type.
== Identifying an ALPS Document ==
ALPS vocabularies are identified by a unique URI. This URI can be in the form
of a resolvable URL (i.e. +http://example.org/alps/accounting+) or it can be
in the form of a URN (i.e. TK).
If the identifier is a URL, it SHOULD point to a valid ALPS document. the URL
MAY point to a human-readable document that describes the ALPS specification
for the identified use case. If the identifier is a URN, it SHOULD NOT be
treated as a resolvable identifer and instead SHOULD be treated as a unique
name for the identified use case.
[I almost feel like we should have two URLs, an ALPS permalink and a
human-readable doc. Or should we suggest the use of content
negotiation? -leonardr]
All ALPS URIs MUST be unique and all ALPS documents intended for
public consumption SHOULD be registered in the ALPS Registry located
at [TK].
== ALPS Documents ==
ALPS Documents contain a machine-readable collection of semantic
descriptors and their human-readable details. An ALPS document can be
represented in either XML or JSON format. This section identifies the
general elements and properties of an ALPS document, their meaning,
and their use. Additional subsections provide specific details on how
to construct a valid ALPS document in XML and in JSON format.
=== Compliance ===
An implementation is not compliant if it fails to satisfy one or more of the
MUST or REQUIRED level requirements. An implementation that satisfies all
the MUST or REQUIRED level and all the SHOULD level requirements is said
to be "unconditionally compliant"; one that satisfies all the MUST level
requirements but not all the SHOULD level requirements is said to be
"conditionally compliant."
[NOTE]
===========================================
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in RFC 2119.
===========================================
=== ALPS Document Properties ===
The ALPS media type defines a small set of properties. The properties
appear in both the XML and JSON formats, but are expressed in
different ways. Below is a list of the properties that can appear in
an ALPS document.
==== +alps+ ====
Indicates the root of the ALPS document. This MUST be the first property
in the document. This property SHOULD have one or more +element+ child
properties.
[Would it be okay to remove the 'must be the first property in the
document' requirement? This would allow an ALPS doc to be embedded in
other docs. It would also make it possible to define ALPS as a
microformat. -leonardr]
==== +appears+ ====
Indicates the appearance rules to apply to the related +element+.
Valid values for this element are: 'MUST', 'SHOULD', and 'MAY'. These
values are to be treated as defined in RFC 2119. The +appears+
property SHOULD appear as a property of the +element+ and/or +child+
elements. If this property does not appear, the value SHOULD be
treated as 'MAY'.
[You've removed MUST NOT and the default MUST NOT for top-level
elements, which makes it difficult to define documents like
hCalendar. I've written an alternate section below. -leonardr]
Indicates the appearance rules for the related +element+ in a
representation. All valid values for this property are terms defined in RFC
2119, and have the meaning given in that standard.
The +appears+ property MAY appear as a property of the +element+
block. This controls whether the element may appear at the "top
level"; that is, not enclosed in any other element defined by this
ALPS document. The formal meaning of "top level" varies by the media
type; see "Applying ALPS to Existing Media Types" for
definitions. [that's TK -leonardr]
Valid values for +appears+ in an +element+ block are: 'MUST',
'SHOULD', 'MAY', and 'MUST NOT'. If this property does not appear, the
value SHOULD be treated as 'MUST NOT'.
The +appears+ property MAY appear as a property of a +child+
block. This controls the rules by which the referenced element may
appear as a child of the enclosing +element+. The formal meaning of
"enclosing +element+" varies by the media type; see "Applying ALPS to
Existing Media Types" for definitions. [that's TK -leonardr]
Valid values for +appears+ in an +child+ block are: 'MUST',
'SHOULD', and 'MAY'. If this property does not appear, the value
SHOULD be treated as 'MAY'.
==== +cardinality+ ====
Indicates the number of times the related +element+ can appear. Valid
values are 'single' and 'many'.
The +cardinality+ property MAY appear as a property of an +element+
block. This controls how many times that element may be used at the
"top level" within a single representation.
The +cardinality+ property MAY appear as a property of a +child+
block. This controls how many times the child element may occur within
its enclosing element.
If this property does not appear, the value SHOULD be treated as
'many'.
==== +child+ ====
Links to a child element of the related +element+ This MAY appear in
the ALPS document as a child of an +element+ block. The +child+
property MAY have an +href+ property pointing to a definition of an
+element+ block (see +href+ for details).
If no +href+ appears, then the +child+ property takes on the same
features as the +element+ property. [Which ones? It would also be good
to mention here which properties the +child+ tag supports, as you do for
+element+. -leonardr]
==== +description+ ====
A text field that contains free-form, usually human-readable, text.
A +description+ block SHOULD appear as a child of +element+. When
present, it describes the meaning and use of the related +element+.
A +description+ block MAY appear as a child of +child+. When present,
it describes the meaning of the relationship between the +element+ and
its +child+.
A +description+ block MAY appear as a child of +alps+. When present,
it describes the purpose of the ALPS document as a whole.
[When writing the example docs I kept wanting to use HTML
markup. Obviously you can do this in ALPS+XML by using namespaces. Can
we explicitly say that the contents of +description+ may be HTML
markup, a la the contents of an Atom story? -leonardr]
==== +element+ ====
Identifies a semantic descriptor. One or more +element+ blocks SHOULD
appear as children of the +alps+ property.
This property MUST have the following properties:
* +id+
* +type+
It SHOULD have the following properties:
* +appears+
It MAY have the following properties:
* +cardinality+
* +child+
* +description+
* +name+
==== +name+ ====
Indicates the name of the +element+ as found in generic
representations. It MAY appear as a property of the +element+.
This is used when the +element+'s name is used as an +id+ value
elsewhere in the ALPS document. For instance, if a single ALPS
document defines an element descriptor called 'customer' and a
safe-idempotent control called 'customer', they can't both have
+id="customer"+ in the ALPS document. One of them needs to have some
other +id+, and to set +name="customer"+.
==== +href+ ====
Points to an +element+ either within the existing ALPS document or in
another ALPS document.
The +href+ attribute MUST appear as part of the +child+ element. The
value MUST be a valid URL, with a fragment identifier, resolving to an
+element+ within an ALPS document.
[Should <alps> itself support +href+ so it can link to itself or a
full human-readable doc? Or should we allow a general <link> tag so
you can do rel="help"?]
\[ Earlier you said that +child+ didn't need href. -leonardr \]
[I have a half-baked idea about using +href+ within +element+ as well.
This would let you copy the +fn+ descriptor defined in hCard into your
custom ALPS document (for performance reasons) but still make it clear
that your +fn+ descriptor has the same meaning as the one defined in
hCard. -leonardr]
==== +id+ ====
A document-wide unique identifier for the related element. This MUST
appear as a property of each +element+.
The value of this property will appear within generic representations
as the name of a semantic descriptor or hypermedia control (see
Applying ALPS to Existing Media Types for details). The exception is
when an element defines +name+ as well as +id+. In that case, the
value of +name+ contains the name of the semantic descriptor or
hypermedia control, and the value of +id+ is just a unique ID.
When applied to an ALPS document, a URI fragment identifier points to
the element with the appropriate +id+. For example, The fragment
identifier +customer+ in the URI +http://example.com/#customer+ refers
to an ALPS element with +id+ set to +customer+.
A relative URL with a fragment identifier (e.g. "#customer") refers to
an element within the ALPS document containing the reference.
==== +type+ ====
Indicates the type of representation control to which the +element+ is
applied. This MUST appear for each +element+. Four values are defined:
\[ Would it be OK to say that the default is 'descriptor'? -leonardr \]
* 'descriptor' refers to a state element (e.g. +HTML.SPAN+, +HTML.INPUT+, etc.).
* 'safe-idempotent' refers to a hypermedia control that triggers a safe,
idempotent state transition (i.e. +HTTP.GET+, +HTTP.HEAD+, etc.).
* 'unsafe-idempotent' refers to a hypermedia control that triggers an
unsafe, idempotent state transition (i.e. +HTTP.PUT+, +HTTP.DELETE+ etc.).
* 'unsafe-nonidempotent' refers to a hypermedia control that triggers an
unsafe, non-idempotent state transition (i.e. +HTTP.POST+).
\[ How about just idempotent and nonidempotent? -leonardr \]
==== +version+ ====
Indicates the version number of the ALPS document. This SHOULD appear as a
property of the +alps+ property. Currently the only valid value is '1.0'.
If no value appears, then it SHOULD be set to '1.0'.
=== XML Representation ===
The following example shows how ALPS Elements are expressed in the XML
format. This example ALPS+XML document describes a portion of the
hCalendar microformat (http://microformats.org/wiki/hcalendar).
[I put this in because I think an example that ties into something
preexisting is better than an example we made up for RWA.]
---------------------------------
<alps version="1.0">
<description>
hCalendar is a simple, open format for publishing events on the web,
using a 1:1 representation of iCalendar (RFC2445) VEVENT properties
and values in HTML.
</description>
<element id="vcalendar" appearance="MAY">
<description>
A container for one or more events (vevent).
</description>
<child href="#vevent" appearance="MAY">
</element>
<element id="vevent" appearance="MAY">
<description>
A container for one event. See section 4.6.1 of RFC 2445.
</description>
<child href="#dtstart" appearance="MUST">
<child href="#summary" appearance="MUST">
<child href="#location" appearance="MAY">
</element>
<element id="dtstart" appearance="MUST NOT">
<description>
Date/time of the start of the event. See section 4.8.2.4 of RFC 2445.
</description>
</element>
<element id="summary" appearance="MUST NOT">
<description>
Short synopsis, title, or name of the event. See section 4.8.1.12
of RFC 2445.
</description>
</element>
<element id="location" appearance="MUST NOT">
<description>
Tells where the event is to be held. May be represented by nested
hCard record, adr record, geo record, or combination thereof. See
sections 4.8.1.7 and 4.8.1.6 of RFC 2445.
</description>
</element>
</alps>
---------------------------------
This ALPS+XML document describes the +rel-nofollow+ microformat
(http://microformats.org/wiki/rel-nofollow):
[And I put this other example in because hCalendar doesn't define any link
relations. -leonardr]
---------------------------------
<alps version="1.0">
<element id="nofollow" type="safe-idempotent">
<description>
Indicates that the referred resource was not necessarily linked to
by the author of the page, and thus said reference should not afford
the referred resource any additional weight or ranking by user
agents.
</description>
</element>
</alps>
---------------------------------
[leaving in this example because a) i don't want to cut it
unilaterally, and b) I didn't change the JSON example
below. -leonardr]
---------------------------------
<alps version="1.0">
<element id="hmaze" type="descriptor" appears="MUST">
<description>Indicates the root of an hMaze document.</description>
<child href="#collection"/>
<child href="#item"/>
<child href="#error"/>
<child href="#cell"/>
<child href="#inventory-link"/>
</element>
<element id="collection" type="descriptor">
<description>A collection of mazes.</description>
<child href="#cell" cardinality="many" appears="MAY">
<description>The opening cell of a maze</description>
</child>
</element>
<element id="item" type="descriptor">
<description>A single maze.</description>
<child href="#start"/ appears="SHOULD">
</element>
<element id="start" type="safe-idempotent">
<description>The beginning cell of a maze.</description>
</element>
<element id="error" type="descriptor">
<description>An error message.</description>
</element>
<element id="cell" type="descriptor">
<description>A cell in a maze.</description>
<child href="#title" appears="SHOULD">
<description>The name of the cell, e.g. "Throne Room."</description>
</child>
<child href="#north" appears="MAY"/>
<child href="#south" appears="MAY"/>
<child href="#east" appears="MAY"/>
<child href="#west" appears="MAY"/>
<child href="#exit" appears="MAY"/>
<child href="#current" appears="MUST"/>
</element>
<element id="north" type="safe-idempotent">
<description>The cell to the north of this one.</description>
</element>
...
[similarly for south, east, west, exit, current.]
...
<element id="inventory-link" external_id="inventory" type="safe-idempotent">
<description>The player's inventory.</description>
</element>
<element id="inventory" type="descriptor">
<description>
Everything the player is carrying.
</description>
<child href="#treasure" cardinality="many" appears="MAY"/>
<child href="#score" appears="MAY">
<description>The player's total score.</description>
</child>
</element>
<element id="treasure" type="descriptor">
<id>treasure</id>
<description>A treasure found in the maze.</description>
<child href="#title" appears="SHOULD">
<description>The name of this treasure, e.g. "Amethyst."</description>
</child>
<child href="#score" appears="MAY"/>
<child href="#pickup" appears="MAY"/>
<child href="#drop" appears="MAY"/>
</element>
<element id="title" type="descriptor">
<description>A title.</description>
</element>
<element id="score" type="descriptor">
<description>A numeric score.</description>
</element>
<element id="pickup" type="unsafe-idempotent">
<description>Picks up the treasure.</description>
</element>
<element id="drop" type="unsafe-idempotent">
<description>Drops the treasure.</description>
</element>
</alps>
---------------------------------
=== JSON Representation ===
Below shows how ALPS Elements are expressed in the JSON format.
[NOTE]
======
In the JSON format, the +element+ and +child+ properties are each expressed
as an +ARRAY+ and are labeled +elements+ and +children+ respectively.
======
[I think this should be more formally defined. The property
descriptions are hard to read because terms like "child" and "element"
are used for both the ALPS doc and for the generic doc the ALPS doc
describes. Then there's this extra genericness when defining things
like +element+ because we can't use XML-specific terminology like
"tag".
I liked your use of "block" instead of "tag" when defining
+element+. If we consistently use, say, "block" and "attribute", then
when we talk about XML and JSON representations we can say that a
block becomes a tag in XML but a list in JSON, and an attribute
becomes an XML attribute but a key-value pair in a JSON
dictionary. -leonardr]
------------------------------------------------
{
"alps" :
"version" : "1.0",
"elements" : [
{
"id" : "hmaze",
"type" : "descriptor",
"appears" : "MUST",
"description" : "Indicates the root of an hMaze document",
"children" : [
{"href" : "#collection"},
{"href" : "#item},
{"href" : "#error"},
{"href" : "#cell"},
{"href" : "#inventory-link"}
]
},
{
"id" : "collection",
"type" : "descriptor",
"description" : "A collection of mazes",
"children" : [
{
"href" : "#cell",
"cardinality" : "many",
"appears" : "MAY",
"description" : "The opening cell of a maze"
}
]
},
{
"id" : "item",
"type" : "descriptor",
"description" : "A single maze"
"children" : [
{"href" : "#start", "appears" : "SHOULD"}
]
},
{
"id" : "start",
"type" : "safe-idempotent",
"description" : "The beginning cell of a maze"
},
{
"id" : "error",
"type" : "descriptor",
"description" : "An error message"
},
{
"id" : "cell",
"type" : "descriptor",
"description" : "A cell in a maze",
"children" : [
{"href" : "#title", "appears" : "SHOULD",
"description" : "The name of the cell, e.g. \"Throne Room\""
},
{"href" : "#north", "appears" : "MAY"},
{"href" : "#south", "appears" : "MAY"},
{"href" : "#east", "appears" : "MAY"},
{"href" : "#west", "appears" : "MAY"},
{"href" : "#exit", "appears" : "MAY"},
{"href" : "#current", "appears" : "MUST"}
]
},
{
"id" : "north",
"type" : "safe-idempotent",
"description" : "The cell to the north of the current cell."
},
... similary for south, east, west, exit, current ...
{
"id" : "inventory-link",
"external_id" : "inventory",
"type" : "safe-idempotent",
"description" : "The player's inventory"
},
{
"id" : "inventory",
"type" : "descriptor",
"description" : "Everything the player is carrying",
"children" : [
{"href" : "#treasure", "cardinality" : "many", "appears" : "MAY},
{"href" : "#score", "appears" : "MAY",
"description" : "The player's total score"
}
]
},
{
"id" : "treasure",
"type" : "descriptor",
"description" : "A treasure found in the maze",
"children" : [
{"href" : "#title", "appears" : "SHOULD",
"description" : "The name of this treasure, e.g. \"Amethyst\""
},
{"href" : "#score", "appears" : "MAY"},
{"href" : "#pickup", "appears" : "MAY"},
{"href" : "#drop", "appears" : "MAY"}
]
},
{
"id" : "title",
"type" : "descriptor",
"description" : "A title"
},
{
"id" : "score",
"type" : "descriptor",
"description" : "A numeric score"
},
{
"id" : "pickup",
"type" : "unsafe-idempotent",
"description" : "Picks up the treasure"
},
{
"id" : "drop",
"type" : "unsafe-idempotent",
"description" : "Drops the treasure"
}
]
}
-----------------------------------------
== Applying ALPS to Existing Media Types ==
ALPS documents can be applied to many existing hypermedia types. Below
are a set of instructions on how to apply ALPS information to existing
media types.
[There's an issue of policy here. I've written two paragraphs. Each
has its own problems. I think I have to vote for #1. -leonardr]
These instructions are to be considered normative for ALPS version
1.0. If the body responsible for a given media type adopts conflicting
instructions for applying an ALPS document to that media type, a new
revision of the ALPS standard will be released which references that
body's instructions.
OR
These instructions are not to be considered normative. If the body
responsible for a given media type adopts conflicting instructions for
applying an ALPS document to that media type, those instructions
should take precedence.
=== ALPS and HTML ===
The following rules apply when applying ALPS to HTML. (That is, to
documents with media type +text/html+ or +application/xhtml+xml+.)
'descriptor' :: The element's name refers to the +"class"+ attribute
of an element. If the descriptor is a +child+ of a transition, the
element SHOULD be a +<INPUT>+, +<SELECT>+, or +<TEXTAREA>+ element.
'safe-idempotent' :: The element's name refers to the +"class"+
attribute of a +<FORM>+ which has its +"method"+" attribute set to
+get+. The names of any +child+ descriptors refer to the +"class"+
attributes of +<INPUT>+, +<SELECT>+, and/or +<TEXTAREA>+ elements
encapsulated by the +<FORM>+.
If no +child+ descriptors exist, the descriptor name may also be applied
to the +"rel"+ attribute of an +<A>+ or +<LINK>+ element.
[I think this should be applied to the class of the submit button, not
the form itself, because a form may contain more than one submit
button. But, it might be okay to say that it can be applied to the
form or to a submit button. -leonardr]
'unsafe-idempotent' :: Treated as equivalent to 'unsafe-nonidempotent'.
'unsafe-nonidempotent' :: The element's name refers to the
+"class"+ attribute of a +<FORM>+ which has its +"method"+ attribute
set to +post+. The names of any +child+ descriptors refer to the
+"class"+ attributes of +<INPUT>+, +<SELECT>+, and/or +<TEXTAREA>+
elements encapsulated by the +<FORM>+.
==== NOTES ====
Since HTML has no support for idempotent state transitions per se,
this standard treats them the same as non-idempotent state
transitions. Both are represented as HTML forms with +method="post"+.
[I think this is better than leaving it undefined, but I'm open to
counterarguments. -leonardr]
=== ALPS and Collection+JSON ===
The following rules apply when applying ALPS to Collection+JSON. (That
is, to documents with media type +application/vnd.collection+json+.)
'descriptor' :: The element name refers to the +"name"+ property of a
+{"data"}+ object.
'safe-idemptotent' :: The element name refers to the +"rel"+ property of
a +{"link"}+ object.
'unsafe-idempotent' :: The element name refers to the +"rel"+ of a
+{"template"}+ object.
'unsafe-nonidempotent' :: Undefined for Collection+JSON.
==== NOTES ====
Since Collection+JSON does not support non-idempotent transitions, it
is up to the application implementor how and whether to represent this
transition in a Collection+JSON representation.
=== ALPS and HAL ===
When applying ALPS to HAL (both XML and JSON formats), the folloiwng
rules apply.
'descriptor' :: The element name refers to the "name" attribute of an item.
'safe-idempotent' :: The element name refers to the "rel" of a link element.
'unsafe-idempotent' :: The element name refers to the "rel" of a link element.
'unsafe-nonidempotent' :: The element name refers to the "rel" of a
link element.
==== NOTES ====
HAL does not identify the protocol-level details of a state transition
(safe/unsafe, idempotent/non-idempotent) within a
representation. Instead that information is in the human-readable
documentation associated with the link relation value. For this
reason, it is important to reference the application's documentation
after determining which ALPS element name applies to a HAL +<LINK>+
element.
[WARNING]
=========================================
MCA: I stopped editing at this point. The Siren+JSON, Atom, and OData
sections still need to be brought up-to-date with the rest of the spec.
LEONARDR: I also stopped here when going through it.
=========================================
=== ALPS and Siren ===
When appying ALPS to Siren, the following rules apply.
* 'unique' : Undefined. (Alternately: the same as "descriptor")
* 'descriptor' : On the top level, element ID refers to the "class" of an entity.
Within an entity, element ID refers to the "class" of a sub-entity, or
to a key within the entity's 'properties' dictionary. [TK uneasy about
this one, but it seems to require both.]
* 'link-relation' : Within an entity, element ID refers to the "rel" of an
item in the entity's "links" dictionary, or to the "rel" attribute of
a sub-entity. Alternatively, the Element ID may refer to the "class" of an item in
the entity's "actions" dictionary, so long as the action's "method" is
GET. If this is the case, sub-elements of type "descriptor" refer to
values for "name" in the action's "fields" dictionary.
* 'idempotent-relation'
* 'unsafe-relation' : Within an entity, element ID
refers to the "class" of an item in the entity's "actions"
dictionary. For "idempotent-relation", the action's "method" must be
GET, PUT, or DELETE. For "unsafe-relation", any method is acceptable.
Sub-elements of type "descriptor" refer to values for "name" in the
action's "fields" dictionary.
=== ALPS and Atom ===
When applying ALPS to Atom, the following rules apply.
=== ALPS and OData ===
When applying ALPS to OData, the following rules apply.
=== Linking to ALPS documents ===
When a representation links to an ALPS document describing its
semantics, the "describedBy" link relation (found in the IANA link
registry) SHOULD be used to describe the relationship between the
representation and the ALPS document.
A single representation may be "describedBy" more than one ALPS
document. If two ALPS documents give conflicting semantics for the
same element, the document linked to earlier in the representation
SHOULD take precedence.
== References ==
== Authors ==
Mike Amundsen <[email protected]>
Leonard Richardson <[email protected]>