-
Notifications
You must be signed in to change notification settings - Fork 68
/
Copy pathAirBnB.xml
196 lines (174 loc) · 9.09 KB
/
AirBnB.xml
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
<?xml version="1.0"?>
<token>
<name>AirBNB Booking</name>
<!-- you will see a lot of actions being defined from here. -->
<!-- Actions are available when the asset card is open, or when
the asset instance is click-and-hold by a user -->
<!-- First, the asset card. -->
<!--
Singapore Telcom 13:45 31 Jan 2018 4G
+-----------------------------------------------+
+-----------------------------------------------+
| AirBNB Booking |
| BELONG EVERYWHERE |
| |
| +-------------------------------------------+ |
| | | |
| | + Create a new booking | |
| | | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | 31 Jan 2018 á 2 Feb 2018 | |
| | | |
| | 92 Elias Road, Singpaore, 519951 | |
| | | |
| | 2 Bedroom unit, check in after 1pm | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | 2 Feb 2018 á 6 Feb 2018 | |
| | | |
| | 9 Lemke Street, Muirhead, NT 0810 | |
| | | |
| | 3 Bedroom house, self-check in | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | 7 Feb 2018 á 13 Feb 2018 | |
| | | |
| | Unit 1519, 28 Harbour Street, NSW 2000 | |
| | | |
| | 2 Bedroom unit, checkin after 1pm. | |
| +-------------------------------------------+ |
| |
+-----------------------------------------------+
◀ ◉ ◼
-->
<!-- Then, the asset instance, which happens after the user
clicked the first asset instance "92 Elias Road..." -->
<!--
Singapore Telcom 13:45 31 Jan 2018 4G
+-----------------------------------------------+
+-----------------------------------------------+
| |
| AirBnB Booking |
| |
| 92 ELIAS ROAD, SINGAPORE, 519951 |
| |
| Checkin: 31 Jan 2018 1pm + 6pm |
| Checkout: 2 Feb 2018 10am |
| |
| Landlord: VeryHappyBunny |
| |
| +--------+ +----+ +--------+ +----+ +-------+ |
| |Transfer| |Lend| |Check in| |Sell| |Auction| |
| +--------+ +----+ +--------+ +----+ +-------+ |
| |
| |
| Conversation history |
| |
| +-------------------------------------------+ |
| | | |
| | You: We are travellers form Australia | |
| | Judging from the pictures you ha^e | |
| | a ^eranda? | |
| | | |
| | VeryHappyBunny: A patio actually, you | |
| | can use any time. | |
| | | |
| | (You confirmed booking) | |
| | | |
| | You: Good, we will get there after lunch. | |
| | | |
| +-------------------------------------------+ |
| |
| |
+-----------------------------------------------+
◀ ◉ ◼
-->
<!-- ON THE DESIGN CHOICE OF DECLARING ACTIONS
At first, it seems that instead of defining actions in XML, we can
gain more flexibility by designing it in a way that they are returned
dynamically, e.g. by callbacks. There are cases where such flexibility
is desirable, for example, when the availability of an action or even
the name of it depends on token status or external input (availability
of a server, for example). But that doesn't contradict with the design
of defining actions in XML, since an action defined in XML can be
enabled or disabled by javascript code when the need
rises. Furthermore, defining actions as separate entity, outside of
the javascript code have the advantage that they can be influenced by
user-agent policy (e.g. a policy of "never attest identity" leads to
certain actions being disabled instead of Dapp hanging there in a
deadlock), easily examined for breaches (an action that is not defined
and signed will not appear as a result of program execution), easily
understood by the wallet (e.g. a wallet can examine an action that
leads to outgoing transfer of value before the user start the action)
and finally, easily translated.
-->
<!-- ON THE DESIGN CHOICE OF DEFINING ACTIONS ON TOKEN TYPE, NOT
ON INDIVIDUAL TOKEN INSTANCES
Imagine an international traveller with 3 bookings in Indonesia,
Singapore and Malaysia, with a huge back pack and a luggage bag in his
hand in front of a smart lock. He should not have to fiddle with his
mobile, choosing the right booking to unlock the smart lock.
The actions and conditions are not mapped to individual instance of
AirBNB booking, but with a type of asset in whole. The same is true
for most digital asset (non-fungible token) types - the selection of
token for the action should be automatic if it can be automated.
-->
<action call="always"> <!-- always display a call-to-action -->
<!-- Display this action even when the user don't have a valid
booking. Some users feel nervous if they couldn't find
the button to display a QR code before their travel time.
Let's give them the button and apologize when they hit
it. -->
<name>Display QR code</name>
<selection filter="(&(checkinTime >= $NOW)(checkoutTime <= $NOW))"/>
<noselection xml:lang="en">
<!-- this message appears when the user hit Display QR
code call-to-action without owning a valid booking
-->
<p>None of your booking is available now.</p>
<!-- there must be a way to generate a card at such
occassion, because some designers consider that a
user with no no valid token trying to use the
starting point of buying one such token. -->
</noselection>
</action>
<!-- this action is triggered when the user places his mobile on the smart lock -->
<action call="none" automatic="yes">
<name>Enter via NFC</name>
<!-- conditions can be defined here or handled by
Javascript. Some conditions apparently has to be here, like
this NFC one, since you can't loop a javascript event code
forever in user's mobile phone just to wait for an NFC
scanner -->
<act on="NFC-sensored">
<params><!-- parameters to match the NFC scanner --></params>
<!-- the following message will never be displayed because
the action can't be triggered by user (see
display="none") -->
</act>
<noact xml:lang="">
<p></p>
</noact>
<!-- the author might choose to not to specify the selection;
instead, handle it through the javascript in the action
card. I'll give an example:
In the case of a video game player with game assets, the
author may choose to render a Horadric Cube for selecting
items in an action called TRANSMOGRIFY. If she intends to
do so, she needs to specify a selection rules here for
the items that one can put in the Horadic Cube (almost
everything) and let user choose what actual pieces to
transmogrify in the action.
In this action, it is not needed. since the logic to
match an NFC scanner's ID with the token's lodging ID
(the process to match if the user is trying to unlock the
right AirBNB room) can be rather complex. -->
<selection non-empty="">
</selection> <noselection> <message xml:lang="en">No tokens
that allows the use of this</message> </noselection> <when>
<!-- the protocol to access the NFC scanner defined here -->
</when> </action> <action display="always" </token>