Information model for interactions

[mmccool]

When a complex response occurs, such as paginated results or query results, these have their own information model distinct from the core information model of the data stored in the directory. This impacts how the returned data is processed by the consumer, i.e. if we are returning JSON-LD, we probably want to treat nested TDs using their own context, and not include other bits like "next-page links" used only to manage the interaction.

To do: add separate section describing interactions, possibly including their own information models, and specify how RDF-based consumers of this information should operate.

[mmccool]

See also w3c/wot-security#166 which lists several use cases for "variant TDs" being returned.

[mmccool]

So this problem goes away if we use the protocol to do pagination...

[farshidtz]

So this problem goes away if we use the protocol to do pagination...

If you are referring to HTTP's chunked transfer encoding (#117 (comment)), this requires loading of the entire collection before being able to parse the JSON array on the client side. The server may also need to construct the JSON manually. Unless we use something like JSON Lines (See #93) to make each TD an independant resource object. I think chunked transfer encoding goes hand-in-hand with RESTful pagination, i.e. if a page contains huge TDs, it will be transferred in chunks.

If you are referring to HTTP Range Requests, it can be used for both byte ranges or TDs. It is a good option, except that the ranges are given in request headers and not in the URL. We can extend it by adding query range arguments and next links and we will end up with what we are proposing in #130.