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

[chrysn <[e-mail]>]

hello core-interfaces authors,

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.

best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom