Subject: [core] SenML: bn/n URI clarification

From: Christian Amsüss <[email-masked]>
Date: Fri, 22 Jul 2016 12:21:49 +0200

Hello SenML users,

I've read the current draft in the sense that `bn` and `n` are
URI-concatenated; yesterdays' 1400 meeting has shown that this is not
the authors' intent, and the following WG meeting that we don't want to
go that way either because names are not necessarily URIs and actually
used thusly. The semantics of `bn` and `n` will therefore stay such that
`bn` and `n` are joint using string concatenation.

To keep SenML suitable for representing linked batches, I suggest that
if the names have URI semantics (which the application would probably
know because the interface it's using on says so, ie. core-interfaces et
al should be updated to say that representations are SenML with URI
semantics), the `bn+n` concatenation should be treated as relative to
the requested URI. That facilitates expressing both external and
internal URIs without the need to know and repeat one's own URI.

This would need changes in the 4.3 section (maybe also other occurrences
of Base Name) which currently says that an absent base name has the
semantics of the requested URI being the base name, and given the
general tendency not to have slash-terminated URIs, an empty base name
would give unexpected results. My impression is that people who treat
their names as non-URI strings might not want that (or even have
interpreted it that way for otherwise it would have come up) -- or are
you all just always setting bn?

Cullen (as you've most prominently spoken out against URIs here) and
others, what is your take on this?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Jul 2016 13:16:36 +0200

I’d prefer to just form an extension that was similar to bn and n but had URI concatenation semantics. 

One of my worries is that people that are naming things like bn=“foo” and n="/bar” would be very surprised when the result used to be “foo/bar” and it suddenly became “/bar”

I’d be glad to help write and extension like this 

> On Jul 22, 2016, at 12:21 PM, Christian Amsüss <[email-masked]> wrote:
> 
> Hello SenML users,
>

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 22 Jul 2016 20:02:32 +0200

Hello Cullen, hello group,

> had URI concatenation semantics. 

This is worth considering IMO ("u" for URL is alredy used, href / base
href might be candidates). It would separate name and URI users -- I'm
not sure yet whether this would be good (because it clears things up and
reduces conflict) or bad (because it limits interoperability).

> One of my worries is that people that are naming things like bn=“foo”
> and n="/bar” would be very surprised when the result used to be
> “foo/bar” and it suddenly became “/bar”

The suggestion I have made in the quoted mail would not have that
effect, we'd stick to string-concatenating bn and n. Just when an
application wants to treat the resulting string as a URI, that would be
interpreted in the context of the site (instead of, as the draft is now,
always requiring full absolute URIs whenever a bn is given).

Right now bn defaults to being the requested URI. I do not know whether
"plain name users" are aware of that and always set a base name to a
unique prefix (global uniqueness of the result is required right now),
whether they are aware and are OK with the resulting name being an URI,
or whether they'd be surprised if an implementation did a string
concatenation of the requested URI and the name.

Which patterns are actually useful or in use when using plain names?

Best regards
Christian

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 23 Jul 2016 03:52:48 -0600

> On Jul 22, 2016, at 12:02 PM, Christian Amsüss <[email-masked]> wrote:
> 
>> 

I’m less keen on things where what stuff means changes depending on what applications is using it. For things that perhaps just validate and pretty print SenML they might not even know what the context was. We’ve been using SenML as a normalized format for storage of data in a big data system and there it is also no clear the context.