- From: Dietrich Schulten <ds@escalon.de>
- Date: Fri, 30 Oct 2015 12:52:58 +0100
- To: public-hydra@w3.org
Hi,
Am 29.10.2015 um 23:24 schrieb Karol Szczepański:
> Hi Markus
>
> Well, first of all - not all variables needs to be replaced. Consider
> query string parameters - these are usually optional
what makes you think so?
hydra:next </gadgets?page=4>
;-)
> and if no suitable
> value is provided the query string parameter should be removed (this is
> doable easily).
hydra:IriTemplate is based on RFC 6570 by default, i.e. a Hydra service
can use all of its features (op-level2 and op-level3 operators and
modifier-level4 value modifiers), and a generic client better prepares
for them. One would probably not want to attempt implementing all the
nifty features of UriTemplate, but simply use an existing library for
UriTemplate expansion [1]. Otherwise, look at the tests[2] such an
implementation will have to pass.
[1] https://code.google.com/p/uri-templates/wiki/Implementations
[2] https://github.com/uri-templates/uritemplate-test
> Other thing is when a variable sits in the path.
A path variable is not a required variable in UriTemplate, rather when
there is a path variable and its value is empty or undefined, you get
different expansions:
empty=""
undef=null
/foo{/empty}/bar /foo//bar
/foo{/undef}/bar /foo/bar
A service would have to make them required in the hydra description of
the variable mapping if it thinks the value must be present. Otherwise
the UriTemplate expansion happily feasts on your undefined path segment
variable ;-P
Best regards,
Dietrich
Received on Friday, 30 October 2015 11:53:29 UTC