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 doesn't have a name (e.g. senml.rnc) 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 JSON 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 added 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.
Hello Ari,
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 doesn't have a name (e.g. senml.rnc) 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 JSON 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 added 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