Subject: Re: [apps-discuss] SenML

From: Yusuke DOI <[email-masked]>
Date: Thu, 01 Mar 2012 18:26:43 +0900

Hi,

I have a question on EXI use.

Is it practical to allow both strict (SHOULD) and non-strict (MAY) ?

In this case, some nodes may not have non-strict grammar. So, nonstrict-capable-and-extended-sender and strict-no-extension-receiver must make some agreement to make a communication in strict mode.

IMHO, I like strict schema-informed (because it can reduce or eliminate dynamic memory allocation).

Regards,

Yusuke

(2012/02/23 23:24), Jari Arkko wrote:
> Hello again,
>
> This is another draft that we'd like to get feedback on. It is yet another component that the authors have used in their work around small and smart devices. The goal is to define a base data format that sensors and other Internet of Things devices can easily use, preferably without having to define entirely new schemes and different structures just to measure a slightly different thing.
>
> http://tools.ietf.org/html/draft-jennings-senml-08
>
> The abstract says:
>
> This specification defines media types for representing simple sensor
> measurements and device parameters in the Sensor Markup Language
> (SenML). Representations are defined in JavaScript Object Notation
> (JSON), eXtensible Markup Language (XML) and Efficient XML
> Interchange (EXI), which share the common SenML data model. A simple
> sensor, such as a temperature sensor, could use this media type in
> protocols such as HTTP or CoAP to transport the measurements of the
> sensor or to be configured.
>
> Comments appreciated. Necessary? Correctly defined? Improvement suggestions?
>
> Jari
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Zach Shelby <[email-masked]>
Date: Thu, 1 Mar 2012 15:32:51 +0200

Hi Yusuke,

Our main use case for the senml+exi representation is for strict mode. We believe the vast majority of implementations will be configured in this mode as it makes the most sense for M2M applications as you point out. The only reason we included a MAY for non-strict was to allow such use. However if as you point out that might cause interoperability problems, I would be in favor of making strict mode a MUST.

Thanks!
Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Jari Arkko <[email-masked]>
Date: Thu, 01 Mar 2012 15:45:47 +0200

I am in support of strict-only. IMO, you do it if you need to conserve space and code as much as possible. If you don't, pure JSON mode of SenML may actually be the right choice for you.

Jari

---

From: liu dapeng <[email-masked]>
Date: Thu, 1 Mar 2012 23:49:21 +0800

Hi all,

Seems SenML only support gathering information from the sensors. What
if people want to control the sensor, e.g. send a command to and
expect a response from the sensor?

regards,
Dapeng Liu

2012/2/23, Jari Arkko <[email-masked]>:
> Hello again,
>
> This is another draft that we'd like to get feedback on. It is yet another
> component that the authors have used in their work around small and smart
> devices. The goal is to define a base data format that sensors and other
> Internet of Things devices can easily use, preferably without having to
> define entirely new schemes and different structures just to measure a
> slightly different thing.
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Zach Shelby <[email-masked]>
Date: Thu, 1 Mar 2012 20:30:03 +0200

Hi,

> expect a response from the sensor?

In this version of SenML, we actually extended the model to handle parameters, actuators and other resources typically found on embedded devices (it really was just for sensor readings in previous versions). We also improved its applicability to representations that result from REST requests. To get a better picture of how SenML can be used with a REST design for sensors, parameters, actuators and batch collections take a look at this draft:

http://tools.ietf.org/id/draft-shelby-core-interfaces-01.txt

Zach