Subject: Re: [apps-discuss] SenML

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

Hi Sebastian,

Your suggestions for optimizing the XSD for EXI use would be very welcome. Looking forward to it! 

Thanks,
Zach 

On Feb 29, 2012, at 6:26 PM, Kaebisch, Sebastian wrote:

> 
> Hi all, 
> 
> I have some improvement suggestions concerning the XSD which is used for senML EXI coding. Right now, there are some types defined which are not optimal for small embedded devices. E.g., attribute "t", "ut", and "ver" are typed as "integer". I think, "int" will be enough in that context. Furthermore, I would like to suggest to make some changes in the XSD definitions (e.g., using enumerations) to make the EXI message instances more compact. I will prepare an XSD proposal for the next week for further discussions.
> 
> Best regards
> Sebastian Käbisch
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
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: "Kaebisch, Sebastian" <[email-masked]>
Date: Fri, 9 Mar 2012 16:05:51 +0100

Hello all,

as I already announced last week I would like to provide some improvements of the SenML XSD that would optimize the EXI usage. 

My proposed (major) changes are:

1) change all typed based "integer" elements to "int". An "integer" in the XSD domain is much bigger as a "long". I assume, this was not the intention. 

2) instead of using a "float" value, I would recommend to use the "mantissa" and "exponend" representation. A floating value is always a challenge for constrained devices because of its inefficent processing.

3) use restriction definitions of strings (define maxLength or list all possible values as enumeration). Especially using enumerations results in a smaller message size and avoids string comparison. 

4) instead of using abbreviation of the element/attribute names I would define the full name which makes life easer, e.g., when it comes to debugging of SenML messages. This is one of the strength of EXI where the names of an element/attribute do not effect the EXI message size.

Further small proposals can be seen in the XSD below. 

I would be happy about any feedback. If you have any questions, please do not hesitate to contact me.

Best regards
Sebastian

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://tools.ietf.org/SenML"
    xmlns:senml="http://tools.ietf.org/SenML">

    <xs:element name="SenML">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="Parameter" type="senml:ParameterType" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <xs:complexType name="ParameterType">
        <xs:sequence>
            <xs:element name="Name" type="senml:stringType" minOccurs="0"/>
            <xs:element name="Time" type="xs:int" minOccurs="0"/>
            <xs:element name="UpdateTime" type="xs:int" minOccurs="0"/>
            <xs:element name="Units" type="senml:unitType" minOccurs="0"/>
            <xs:element name="Value" type="senml:FloatValueType" minOccurs="0"/>
            <xs:element name="StringValue" type="senml:stringType" minOccurs="0"/>
            <xs:element name="BooleanValue" type="xs:boolean" minOccurs="0"/>
            <xs:element name="ValueSum" type="senml:FloatValueType" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="BaseName" type="senml:stringType"/>
        <xs:attribute name="BaseTime" type="xs:int" />
        <xs:attribute name="BaseUnits" type="senml:stringType" />
        <xs:attribute name="Version" type="xs:short" />
    </xs:complexType>
    
    <xs:complexType name="FloatValueType">
        <!-- floatValue = value * 10^Exponent -->
        <xs:sequence>
            <xs:element name="Value" type="xs:int"/>
            <xs:element name="Exponent" type="xs:byte"/>
        </xs:sequence>
    </xs:complexType>    
       
    <xs:simpleType name="stringType">
        <xs:restriction base="xs:string">
            <xs:maxLength value="16"/>
        </xs:restriction>
    </xs:simpleType>

    <xs:simpleType name="unitType">
        <xs:restriction base="xs:string">
            <xs:enumeration value="m"/>
            <xs:enumeration value="kg"/>            
            <xs:enumeration value="s"/>
            <xs:enumeration value="A"/>
            <xs:enumeration value="K"/>
            <xs:enumeration value="cd"/>
            <xs:enumeration value="mol"/>            
            <xs:enumeration value="Hz"/>
            <xs:enumeration value="rad"/>
            <xs:enumeration value="sr"/>
            <xs:enumeration value="N"/>
            <xs:enumeration value="Pa"/>            
            <xs:enumeration value="J"/>
            <xs:enumeration value="W"/>
            <xs:enumeration value="C"/>
            <xs:enumeration value="V"/>
            <xs:enumeration value="F"/>            
            <xs:enumeration value="Ohm"/>
            <xs:enumeration value="S"/>
            <xs:enumeration value="Wb"/>
            <xs:enumeration value="T"/>
            <xs:enumeration value="H"/>            
            <xs:enumeration value="degC"/>
            <xs:enumeration value="lm"/>
            <xs:enumeration value="lx"/>
            <xs:enumeration value="Bq"/>
            <xs:enumeration value="Gy"/>            
            <xs:enumeration value="Sv"/>
            <xs:enumeration value="kat"/>
            <xs:enumeration value="pH"/>
            <xs:enumeration value="Percent"/>
            <xs:enumeration value="count"/>            
            <xs:enumeration value="Percent_RH"/>
            <xs:enumeration value="m2"/>
            <xs:enumeration value="l"/>
            <xs:enumeration value="m/s"/>
            <xs:enumeration value="m/s2"/>
            <xs:enumeration value="l/s"/>
            <xs:enumeration value="W/m2"/>
            <xs:enumeration value="cd/m2"/>
            <xs:enumeration value="Bspl"/>
            <xs:enumeration value="bit/s"/>
            <xs:enumeration value="lat"/>
            <xs:enumeration value="lon"/>
            <xs:enumeration value="Percent_EL"/>
        </xs:restriction>
    </xs:simpleType>

</xs:schema>
> -----Original Message-----
> From: Zach Shelby [mailto:[email-masked]]
> Sent: Thursday, March 01, 2012 2:46 PM
> To: Kaebisch, Sebastian
> Cc: [email-masked]
> Subject: Re: [apps-discuss] SenML
> 
> Hi Sebastian,
> 
> > I have some improvement suggestions concerning the XSD which is used for
> senML EXI coding. Right now, there are some types defined which are not
> optimal for small embedded devices. E.g., attribute "t", "ut", and "ver"
> are typed as "integer". I think, "int" will be enough in that context.
> Furthermore, I would like to suggest to make some changes in the XSD
> definitions (e.g., using enumerations) to make the EXI message instances
> more compact. I will prepare an XSD proposal for the next week for further
> discussions.
> >
> > Best regards
> > Sebastian Käbisch
> >

---

From: Yusuke DOI <[email-masked]>
Date: Sat, 10 Mar 2012 02:43:38 +0900

Dear Kaebisch,

I have several comments.

> 2) instead of using a "float" value, I would recommend to use the "mantissa" and "exponend" representation. A floating value is always a challenge for constrained devices because of its inefficent…

I think float values in EXI is already mantissa and exponend (base 10).

> 3) use restriction definitions of strings (define maxLength or list all possible values as enumeration). Especially using enumerations results in a smaller message size and avoids string comparison.

Enumeration is good idea but I think strict enumeration allows no 
addition in future without breaking backword compatibility. I recommend 
some 'dummy entries' to make room (and show the limit to keep the same 
bitwidth clearly) for future.

Yusuke

---

From: "Kaebisch, Sebastian" <[email-masked]>
Date: Wed, 14 Mar 2012 10:50:57 +0100

Dear Yusuke,

thank you for your mail.

> > 2) instead of using a "float" value, I would recommend to use the
> "mantissa" and "exponend" representation. A floating value is always a
> challenge for constrained devices because of its inefficent processing.
> 

That's right, however, EXI has to convert the float value into the mantissa and exponent representation (encoding) and vice versa (decoding) respectively. This processing overhead can be avoided if we working already on data model level only with the mantissa and exponent representation.

> > 3) use restriction definitions of strings (define maxLength or list all
> possible values as enumeration). Especially using enumerations results in
> a smaller message size and avoids string comparison.
> 

If there a need of flexibility, then we should do that. In my understanding, the unit symbol table in 10.1 will be standardized and will be fixed then. 

Best regards
Sebastian Käbisch

---

From: Zach Shelby <[email-masked]>
Date: Wed, 14 Mar 2012 11:56:35 +0200

> If there a need of flexibility, then we should do that. In my understanding, the unit symbol table in 10.1 will be standardized and will be fixed then. 

The unit representation part of the SenML draft is the last thing that is an open issue to fix actually. The value will need to be open-ended as even in the current form this would need to be an IANA registry and thus new values would be added over time. However, we are looking at a model where external unit references can be made instead of trying to standardize a list of units in the IETF. For now at least we should leave this as a string. Let's look at it again when the unit model has been updated in the draft.

Zach

---

From: DOI Yusuke <[email-masked]>
Date: Wed, 14 Mar 2012 22:35:49 +0900 (JST)

Dear Sebastian,

From: "Kaebisch, Sebastian" <[email-masked]>
Subject: RE: [apps-discuss] SenML
Date: Wed, 14 Mar 2012 10:50:57 +0100
> That's right, however, EXI has to convert the float value into the mantissa and exponent representation (encoding) and vice versa (decoding) respectively. This processing overhead can be avoided if…

I cannot get your point. Do you have specific API or something else in mind?

I think both is possible and some library for constrianed devices may
implement something like the latter.

1) encode_exi_float(EXI_STREAM *out_stream, double f);
2) encode_exi_exp(EXI_STREAM *out_stream, int mantissa, int exponent);

Thanks,

Yusuke

---

From: "Kaebisch, Sebastian" <[email-masked]>
Date: Thu, 15 Mar 2012 19:01:32 +0100

Dear Yusuke,

> > That's right, however, EXI has to convert the float value into the
> mantissa and exponent representation (encoding) and vice versa (decoding)
> respectively. This processing overhead can be avoided if we working
> already on data model level only with the mantissa and exponent
> representation.
> 

You are absolutely right, both implementations are possible. My intention was only to point to the processing overhead in "encode_exi_float" (bringing float to mantissa-exponent representation) which can be avoided if we are only working with the mantissa-exponent representation all the time and state this in the senML XSD as well. I have only the very restricted microcontrollers in mind.

Best regards
Sebastian