Re: [core] core-interfaces: "n" in SenML examples vs SenML spec

[Christian Amsüss <[e-mail]>]

Hello working group,

with the renewed interest in the SenML and core-interfaces topics, I'd
like to take up an issue again I've written about roughly a year ago.
(Original mail below for reference; posted back then with another hat on
/ email adress).

This all revolves around how URIs are built when assembling the bn and n
properties from SenML.

I'd like to propose the following treatment of names in SenML:

  The resource a value or sum belongs to is composited from the
  requested URI (if the document is a representation resulting from the
  request of a URI), the base name attribute, and the name attribute, by
  means of consecutive reference resolution ([RFC3986], Section 5.2).
  All those elements are optional, but at least one must be present.

  By the rules of reference resolution, this means that unless the
  requested URI is present, the "bn" (or "n" in absence of "bn") must be
  an absolute URI. The result is always an absolute URI.

Revisiting and adapting the examples from the original mail:

  Req: GET /s/
  Res: 2.05 Content (application/senml+json)
  {"e":[
      { "n": "humidity", "v": 80, "u": "%RH" }],
  }

(The batch resource needs to be accessed with a slash at the end,
corresponding to a trailing empty Uri-Path in CoAP, otherwise the
response would need to look like in the third example or better be
4.04.)

  Req: GET /s/humidity (Accept: application/senml+json)
  Res: 2.05 Content (application/senml+json)
  {"e":[
      { "v": 80, "u": "%RH" }],
  }

(The server might also return "n":"./humidity" or "n":"", but why should
it -- it is already clear from the context that this is about
/s/humidity)

  Req: GET /l
  Res: 2.05 Content (application/senml+json)
  {"e":[
     { "n": "/s/humidity", "v": 80, "u": "%RH" }],
  }

(This can stay unmodified. It's a matter of taste and URI length whether
to all the resource /l or /l/ as long as no relative-path URIs are
involved.)


If my proposal resonates well here, I'd happily write corresponding
patches to draft-jennings-core-senml-00 and
draft-ietf-core-interfaces-01.


Best regards
Christian Amsüss


(original mail for reference)

On Fri, Aug 02, 2013 at 07:15:41PM +0200, chrysn (Christian Amsüss) wrote:
> when researching for the "SenML unit in link format response" post, i
> discovered that core-interfaces, in several places, uses the "n"
> parameter of SenML in a way that looks reasonable, but contradicts
> draft-jennings-senml-10.
> 
> particular examples (some lines removed):
> 
> >    Req: GET /s
> >    Res: 2.05 Content (application/senml+json)
> >    {"e":[
> >        { "n": "humidity", "v": 80, "u": "%RH" }],
> >    }
> 
> >    Req: GET /s/humidity (Accept: application/senml+json)
> >    Res: 2.05 Content (application/senml+json)
> >    {"e":[
> >        { "n": "humidity", "v": 80, "u": "%RH" }],
> >    }
> 
> >    Req: GET /l
> >    Res: 2.05 Content (application/senml+json)
> >    {"e":[
> >       { "n": "/s/humidity", "v": 80, "u": "%RH" }],
> >    }
> 
> while it is clear from the context that the values "80" are
> representations of the /s/humidity resource, the senml spec says:
> 
> >    The Name value is concatenated to the Base Name value to get the name
> >    of the sensor.  The resulting name needs to uniquely identify and
> >    differentiate the sensor from all others.  If the object is a
> >    representation resulting from the request of a URI [RFC3986], then in
> >    the absence of the Base Name attribute, this URI is used as the
> >    default value of Base Name.  Thus in this case the Name field needs
> >    to be unique for that URI, for example an index or subresource name
> >    of sensors handled by the URI.
> 
> concatenation would, in these cases, give the values
> 
> > scheme://host/shumidity
> > scheme://host/s/humidityhumidity
> > scheme://host/l/s/humidity
> 
> respectively. even if it was assumed that the concatenation followed the
> rules of relative url concatenation (like in hyperlinks, i don't know
> where that is defined), the resulting urls would be
> 
> > scheme://host/humidity
> > scheme://host/s/humidity
> > scheme://host/s/humidity
> 
> , which is better but still not there yet. (what makes it even more
> difficult, we'd have to distinguish between "GET /s/" and "GET /s", of
> which i'm not sure how it is mapped to CoAP -- would the former contain
> an empty Uri-Path option?)
> 
> i kindly ask for clarification.


-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[e-mail]  | Arbeitergasse 15, A-4400 Steyr
tel:[phone]                | http://www.energyharvesting.at/
                                      | ATU68476614