- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 13 Oct 2014 20:14:51 +0200
- To: <public-hydra@w3.org>
On 13 Okt 2014 at 18:00, Dietrich Schulten wrote: > Am 13. Oktober 2014 16:14:25 schrieb "Markus Lanthaler" : >> On 6 Okt 2014 at 18:32, Dietrich Schulten wrote: >>> Am 6. Oktober 2014 13:08:48 schrieb "Markus Lanthaler": >>>> On 2 Okt 2014 at 01:18, Dietrich Schulten wrote: >>>>> Am 1. Oktober 2014 17:48:30 schrieb "Markus Lanthaler": >>>> Yep, it defines more constraints ATM. I'm not that much of a fan of the >>>> annotation model it uses (<property>-input / <property>-output) though. >>> >>> Why is that? >> >> Because it kind of defines new properties etc. on the fly whose semantics >> depend on its IRI structure: >> http://schema.org/name -> http://schema.org/name-input > > I see, name-input is of course identified as http://schema.org/name-input > in the context. Possible values however would be defined on schema:name, > not on schema:name-input. > > They *can* express a request template which does not depend on the IRI > structure, but which describes a request body. Yeah, I know. > But from their review POST example it also seems that a request body sent > to an entry point has to be an Action subclass[1]. If that is in fact a > reqirement, it would be quite unusual from a restful point of view, and > makes it difficult to use a potentialAction for an existing ReST service > which does not expect Action request bodies. I haven't checked for a while but it was kind of ambiguous of what to send/expect a while ago. > I am really after an equivalent to html forms which allows me to tell the > client how the request body to a POST should look like, possibly without > forcing it to download rdf descriptions for all request body properties to > learn about the expected values. I have been thinking of ways to support application/x-www-form-urlencoded requests but haven't found an elegant solution yet. -- Markus Lanthaler @markuslanthaler
Received on Monday, 13 October 2014 18:15:22 UTC