- From: Ryan Shaw <ryanshaw@unc.edu>
- Date: Fri, 6 Nov 2015 14:35:28 -0500
- To: Karol Szczepański <karol.szczepanski@gmail.com>
- CC: Dietrich Schulten <ds@escalon.de>, Asbjørn Ulsberg <asbjorn@ulsberg.no>, Tomasz Pluskiewicz <tomasz@t-code.pl>, Markus Lanthaler <markus.lanthaler@gmx.net>, Hydra <public-hydra@w3.org>
>> >> How about the combination of a static hydra:ApiDocumentation and >> >> inline hydra:operation? Would the latter override the former? Is this >> >> described anywhere? >> > >> > This has been discussed in length before. >> >> Can you please point me to this discussion? The relevant thread starts here: https://lists.w3.org/Archives/Public/public-hydra/2014Jun/0054.html And continues here: https://lists.w3.org/Archives/Public/public-hydra/2014Jul/0024.html https://lists.w3.org/Archives/Public/public-hydra/2014Jul/0027.html Thanks to everyone who has contributed to this thread; great discussion. My takeaways so far: 1. There still doesn't seem to be consensus on the function of the API documentation. Markus' position, if I understand correctly, is that the API documentation is a kind of convenience or shortcut for specifying state transitions; rather than or in addition to including this information directly in representations. The advertised state transitions from any specific representation are always the aggregate of 1) the transitions specified in the representation itself PLUS 2) any transitions specified in linked documentation. 2. However at least some others think the API documentation should be interpreted as a kind of overview of what might be possible; a way to document an API using RDF, but always subject to revision by the information in an actual representation. I'm less and less sure that I see the use of having potential state transitions advertised anywhere *other* than in representations, except as a way of generating human-readable documentation. A Hydra client is always going to have to be ready to look for advertisements of possible state transitions in individual representations anyway; so what is the use of complicating client implementation by saying, "hey, here are some other places to look for possible state transitions"? Why not just leave it at "state transitions are advertised in representations, period"? What would be the drawbacks of dropping hydra:supportedOperation from the core vocabulary? Ryan
Received on Friday, 6 November 2015 19:35:57 UTC