- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Wed, 13 Aug 2014 09:36:04 +0200
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, public-hydra@w3.org
>>> Personally I preferred the broader interpretation that this mechanism >>> could do 'anything' with 'any part' of the template URI, including >>> variable substitution, character encoding, uppercasing(!), whatever. Why would we want uppercasing and how far should “whatever” go? Cfr. “Be liberal in what you accept…”. >> >> Yes, that's at least what I want :-) >> >> If you want the template itself to be processed differently, then you are >> changing the semantics of RFC6570. In other words, the IRI template isn't >> RFC6570 conformant anymore. This touches ISSUE-17 [6] for which we have a >> >> PROPOSAL: Introduce a datatype for RFC6570 IRI templates, but >> don't change the range of hydra:template . Update the Hydra >> JSON-LD context to type-coerce template automatically. >> >> Perhaps we should try to close ISSUE-30 and ISSUE-17 at the same time >> instead of postponing the decision on ISSUE-17!? Markus, you said elsewhere that we don't have the goal of describing *any* API, i.e., that APIs sometimes have to follow what Hydra prescribes. The above seems to conflict with that. Any insights into this? > I think it would be wise to stick to the mechanism defined in RFC6570 "URI Template". Going beyond this requires a really compelling use-case IMHO. +1, definitely for a first version. Best, Ruben
Received on Wednesday, 13 August 2014 07:36:39 UTC