-
Notifications
You must be signed in to change notification settings - Fork 8
/
Copy pathTODO
174 lines (119 loc) · 6.09 KB
/
TODO
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
Ideas:
- We should support format (predefined email, uri, etc, recognizers).
- Generadores QuickCheck dentro JSON schemas:
Propongo que permitimos que se especifica una funcion erlang como
schema también, con el significado de que es un generador. Tenemos que
pensar en como especificarlo en jason pero el resto es obvio
Propongo añadir un par de keywords: "jsongen" y "jsonval". Sus values
pueden ser el nombre de una función erlang en el formato
"module:function(params)", para jsongen se devuelve un generador de
json y para el caso de jsonval se devuelve una función que devuelve un
boolean.
+ Que hacer con ?LET, y otros macros. Falta sintaxis in eqc.
- All JSON data are JSON schemas:
Proponemos que todos los datos son JSON schemas, son valores 'literales'.
Problema: que hacer con los JSON schemas.
Un objeto es un JSON schema 'tradicional' si contiene un atributo
"schema" : true.
Dentro schemas tradicionales podemos meter valores literales usando
enum (ya se puede), pero, ojo, permitimos que se mete JSON schemas dentro
otra vez usando "schema : true.
- Uniqueness of names in JSON objects
We need a flag for capturing both semantics:
Is this valid JSON? { "name": "foo", "name": "bar" }
It's technically legal, but strongly discouraged, according to the
RFC (tools.ietf.org/html/rfc4627#section-2.2): "The names within an
object SHOULD [RECOMMENDED] be unique".
Two routes:
Javascript: illegal (and JSON is is supposed to be a subset!)
Python: overwrite the "bar" entry with the latest value
Excerpt from: http://stackoverflow.com/questions/7202477/are-double-definitions-allowed-in-json-and-if-so-how-should-they-be-interprete
- Dependencies (mochijson2) must be automatically solved (rebar?).
- Permit parameters for POST and PUT, in ADDITION to a body. [x]
We probably need a new schema for that (extension of JSON schema).
- How to do things such as support substitution of object values [x]
into query parameters? (i.e., token returned, token used)
Or for that matter in bodies?
One possibility is to extend some kind of substitution syntax for these
entities, e.g., {token} as a literal value inside a schema.
Maybe we can define: "token" : {"from_resource" : "var"}.
Do we do a deep search? Maybe.
- And a QuickCheck operator:
- "pelle" : {"quickcheck" : "name_of_function"} or
"pelle" : {"quickcheck" : {name:"..",others}} which
sends along the JSON object to the QuickCheck function name.
- We could do "token" : {"quickcheck" : {name:"resource-var",var-name:"token"}}
(for now that is ok).
- We need to remove links that depend upon an object upon delete,
And change them upon PUT (this obviously depends on the URI, which
is either linked, or we can link to, the object).
The question is what happens to such indirect things as expressed above,
i.e., permitting the {key} syntax in schema:s and querySchema:s,
when we start delete the object defining the key upon which they rely.
(I guess they should be deleted too, so we have a depends-on relation
for links, this can obviously be transitive).
- We should have convenient operations for defining frequencies, [x]
and for redefining values.
- Maybe define a whole schema using quickcheck [x]
(i.e., define querySchema or schema).
- Recursive link extraction? [x]
{struct,[{<<"channels">>,arr}]}
instead of arr.
- How to handle attributes of (possibly)
multiple instances as arguments to operations.
In general, how to handle arrays?
Would be nice with a member operation (on something, on the return value
of an operation).
The idea is to use the syntax
type.attribute
meaning that we look for attribute in any object having the type.
Possibly we could think of things like var=type;attribute which
introduces a binding that can later be used in var.attribute
to enforce that attributes are used from the same element.
It would be nice if we could separate the binding from the
attribute use, but it is probably not possible.
We can use the syntax xxy<-abc:def (binding), abc:def (an attribute for
any object) and xxy:def (an attribute of a defined variable).
We can even think of saving such variables in the scope,
i.e., so that they are accessible in future links.
But to save a variable we really need an separate assignment,
so that it is not necessary to use an attribute.
Maybe something really ugly like {xxy<-abc:_}.
We could of course do all this also in the Erlang part, and we should
have nice functions for accomplishing such things.
We can use the schema "title" attribute as a type
(and as always, beware of nested types).
So first we try to interprete xxx as a variable, and then as a type.
Question: do we
What is a type name? The name of the file in which a schema resides,
or better, the name of the schema itself.
- Or maybe: links definable over a set of items.
That is, get_people returns an array of people, we can define
a link that reference two members of the array.
- Invariants:
\forall tr\in Tr. tr.sender_net_cer = cer("USD",tr.sender_net.currency)
\forall tr\in Tr. tr.sender_net = tr.sender.net
(inefficient but maybe ok)
But are these invariants over the REST service, or invariants over
the discovered links? (or is this the same?)
- Idea: we can refer to elements in array using the attribute name
that refers to the array, and some other element (in)
"in elements".
Maybe, we could also make variables more unique by
referring to the type (name) where they are introduced,
if there are collisions:
"in channels_epg_response.elements"
What is really unique is the link; we could let attributes refer to the
link (if omitted using the last link) and then a normal JSON pointer expression.
We need also a syntax for referring to any component of an array.
Maybe some syntax ~2 for literally $any, while...
Syntax:
{link.path_expression}
a path expression can contain a special _any_ or $any
identifier to signal any array index.
- Implement an option to simulate exploring a web service,
i.e., don't really do the web service calls but let the reply
be automatically generated by jsongen.
This way we can check that the logic works, without really
having a web service to talk to (simulate mode).
- A store for json objects