RE: Moving forward with ISSUE-30 (IRI template expansion)

> -----Original Message-----
> From: Ruben Verborgh [mailto:ruben.verborgh@ugent.be]
> Sent: Wednesday, August 13, 2014 8:36 AM
> To: Gregg Kellogg
> Cc: Markus Lanthaler; public-hydra@w3.org
> Subject: Re: Moving forward with ISSUE-30 (IRI template expansion)
> 
> >>> 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...".
> 

Yep I agree now - it is unnecessary. I thought Ruben's original proposal was to go beyond RFC6570, but in fact I wasn't aware of the power of RFC6570 (I just read it properly today!), and now I understand why Markus wanted to limit the options here.

> >>
> >> 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.
> 

+1 (and thanks for enlightening me!)

As an 'off-the-top-of-my-head' suggestion - has anyone considered asking the RFC6570 authors or 'community' about extending it to support what we require here? Being fully RFC6570-compliant while also getting datatypes and language support would be great, no? I'm not suggesting we'd wait for an extension or anything, really I'm just curious if anyone else has required this sort of thing from URI Templates before...

> Best,
> 
> Ruben

Received on Thursday, 14 August 2014 21:29:19 UTC