AW: Finalizing the IriTemplate design - serialization (ISSUE-30 & ISSUE-17)

As long as it is still valid to expect and pass an urlencoded scalar for a placeholder, I have no objections. Scalars are what is used in the rfc examples, so that should be a perfectly normal case. IOW, an expansion http://example.com/events?scheduled=true&age=50&price=180.0&place=concert+hall should still be OK.
Also, it should be clear that we are not squeezing something into an Uri which should rather be a POST or PUT request body. A sign for that could be that we post an empty body to an elaborated Uri which looks very much like a request body :)

The fact that the rfc specifically shows an example where {lang} is a template parameter makes me wary that we are overspecifying a bit by introducing a syntax for parameter values which intrinsically tells the language of a value. If the server needs a language to identify a resource, the idea of Uritemplate seems to be that the server would be explicit about it.

Another question, this time about the type syntax: are we still identifying a resource if we encode the xsd type of a value into the value? Because that is what UriTemplate does, it describes a range of resource identifiers, not a general means to send data. Is the xsd type really needed to identify the target resource in a Uri http://example.com/offers?price= %225.5%22%5E%5Exsd%3Axsd%3Adecimal.

Best regards, 
Dietrich 








---- Markus Lanthaler schrieb ----

>Hi folks,
>
>I've re-read all the discussions we had about the design of IriTemplate...
>and we had lots of them :-) This is an attempt to finalize the design.
>
>Let's do this a bit differently this time. In the next days, I'll send out a
>couple of proposals that I think have most consensus. Please let me know if
>you can *not* live with the proposal, and if so, why. To keep the
>discussions focused, I'd like to ask you to refrain from making new
>proposals at this stage. We will go back to the drawing board if we find out
>that we don't have an acceptable solution yet afterwards.
>+1s are of course also welcome, but not really necessary as I'll assume you
>are fine with the proposal in case you don't complain :-)
>
>Let's start with the serialization of URL template variables that includes
>language and type information. The proposal is to
> - serialize IRIs as is
>      http://example.com  --> http://example.com
> - serialize the lexical form of a literal [1] by putting it in double
>quotes, no further escaping
>      He said "what"?  --> "He said "what"?"
> - datatype IRIs are prefixed by two hats (^^)
> - language tags are prefixed by an @ character
> - language-tagged strings are never typed (so the rdf:langString datatype
>IRI is *always* omitted)
> - plain strings (literals of type xsd:string) *may* be serialized without
>datatype IRI
>
>To make this a bit more concrete, let's have a look at a couple of Turtle
>and JSON-LD values and see how they are serialized if used as value of a URL
>template variable.
>
>  <http://example.com>
>  { "@id": "http://example.com" }
>    ----> http://example.com
>  
>  "A simple string"
>  { "@value": "A simple string" }
>    ----> "A simple string"
>    or -> "A simple string"^^http://www.w3.org/2001/XMLSchema#string
>  
>  """Also this " works"""
>  { "@value": "Also this \" works" }
>    ----> "Also this " works"
>    or -> "Also this " works"^^http://www.w3.org/2001/XMLSchema#string
>  
>  "A language-tagged string"@en
>  { "@value": "A language-tagged string", "@language": "en" }
>    ----> "A language-tagged string"@en
>  
>  "5.5"^^xsd:xsd:decimal
>  { "@value": "5.5", "@language": "xsd:decimal" }
>    ----> "5.5"^^http://www.w3.org/2001/XMLSchema#decimal
>
>
>Cheers,
>Markus
>
>
>[1] http://www.w3.org/TR/rdf11-concepts/#dfn-literal
>
>
>
>--
>Markus Lanthaler
>@markuslanthaler
>
>