Draft: draft-ietf-core-senml

Commentary: From - aug 31   , I 'm just putting the finishing touches on an IETF draft to introduce the base time offset attribute that we discussed in Berlin . One thing I noticed was that the IANA considerations section ( 11.2 ) that describes the SenML label registry mentions the need to define the label name , label , json type and xml type for the new attribute . However the SenML draft also defines the CBOR representation and EXI representation . I assume updates to these will also be needed in order to register a new SenML label ? For the XML representation the IANA text mentions the need to define the XML type . However section 7 " XML representation " includes the RelaxNG compact schema . Does this also need to be updated ? and if so how ? Should the entire schema be listed or should a new schema be defined using an " include " construct ? The schema in the SenML draft does n't have a name ( e.g. ) so I 'm not sure how this would be done ? The other issue is that the current compact RelaxSchema enforces ordering of the labels . If I define a new bto attribute I take it that bto should be associated with the base attributes and come after bver and before the regular attributes . I 'm not familiar enough with RelaxNG to detail that without re - including the entire schema . It also leads to the question of what happens with ordering if someone else defines another base attribute . Should bto or the other attribute take precedence after bver ? I think the syntax and draft needs to take this into account . The EXI representation clause 8 in the SenML draft includes an XSD generated from the RelaxNG . Would the generation of the complete schema be required for the addition of an new attribute ? There seems to be similar issues to the RelaxNG schema . For CBOR there 's also the CDDL specification in section 10 . I 'm not that familiar with CDDL but it seems to define an extension mechanism that group the base and regular attributes . There 's no text associated with this section as to the need to define extensions and whether the defining the  label and type is enough for the CDDL . It seems to me that the schemes need to be updated to include some extension points to enable new attributes to be without having to update the schemas . Also given that we have to define these various different representations I wonder if the registry should instead be called the SenML attribute registry ? The reasoning is that the registry would have to include not only JSON labels but the CBOR mapping key etc . Regards , Christian
The SenML Stream is represented as a sensml tag that contains a
series of senml tags for each SenML Record.  The SenML Fields are
represents as XML attributes.  The following table shows the mapping
of the SenML labels to the attribute names and types used in the XML
senml tags.
The SenML Stream is represented as a sensml tag that contains a
series of senml tags for each SenML Record.  The SenML Fields are
represents as XML attributes.  The following table shows the mapping
of the SenML labels, which are used for the attribute name, to the
attribute types used in the XML senml tags.
IANA will create a new registry for SenML labels.  The initial
content of the registry are shown in tbl-json-labels and tbl-xml-
labels.
All new entries must define the Label Name, Label, JSON Type, and XML
Type.
Note to RFC Editor.  Please replace RFCXXXX with the number for this
RFC.
All new entries must define the Label Name, Label, and XML Type but
the CBOR labels SHOULD be left empty as CBOR will use the string
encoding for any new labels.  The ID fields contains the EXI schemaID
of the first Schema which includes this label or is empty if this
label was not intended for use with EXI.  The Note field SHOULD
contain information about where to find out more information about
this label.
The JSON, CBOR, and EXI types are derived from the XML type.  All XML
numeric types such as double, float, integer and int become a JSON
Number.  XML boolean and string become a JSON Boolean and String
respectively.  CBOR representes numeric values with a CBOR type that
does not loose any information from the JSON value.  EXI uses the XML
types.
Extensions that add a label that is intended for use with XML need to
create a new RelaxNG scheme that includes all the labels in the IANA
registry.
Extensions that add a label that is intended for use with EXI need to
create a new XSD Schema that includes all the labels in the IANA
registry then allocate a new EXI schemaID.  Moving to the next letter
in the alphabet is the suggested way to create the new EXI schemaID.
Any labels with previously blank ID values SHOULD be updated in the
IANA table to have their ID set to this new schemaID value.