Skip to content
Snippets Groups Projects
Commit da1fc57b authored by Peter Niblett's avatar Peter Niblett
Browse files

Add node

parent cc395d93
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
CDT-node-v0_8_0.xsd 0 → 100644
+ 118
− 0
View file @ da1fc57b
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright Notification
The oneM2M Partners authorize you to copy this document, provided that you retain all copyright and other proprietary notices
contained in the original materials on any copies of the materials and that you comply strictly with these terms.
This copyright permission does not constitute an endorsement of the products or services, nor does it encompass the granting of
any patent rights. The oneM2M Partners assume no responsibility for errors or omissions in this document.
© 2014, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TTA, TTC). All rights reserved.
Notice of Disclaimer & Limitation of Liability
The information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand
and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations.
No recommendation as to products or vendors is made or should be implied.
NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE,
GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY
PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS.
NO oneM2M PARTNER TYPE 1 SHALL BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY THAT PARTNER FOR THIS DOCUMENT, WITH RESPECT TO
ANY CLAIM, AND IN NO EVENT SHALL oneM2M BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES.
oneM2M EXPRESSLY ADVISES ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER.
-->
<xs:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.onem2m.org/xml/protocols"
xmlns:m2m="http://www.onem2m.org/xml/protocols" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
elementFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:include schemaLocation="CDT-commonTypes-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-memory-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-battery-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-areaNwkInfo-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-areaNwkDeviceInfo-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-firmware-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-software-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-deviceInfo-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-deviceCapability-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-reboot-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-eventLog-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-cmdhPolicy-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-activeCmdhPolicy-v0_8_0.xsd" />
<xs:include schemaLocation="CDT-subscription-v0_8_0.xsd" />
<xs:element name="node">
<xs:complexType>
<xs:complexContent>
<!-- Inherit common attributes for announceable Resources -->
<xs:extension base="m2m:announceableResource">
<!-- Resource Specific Attributes -->
<xs:sequence>
<xs:element name="nodeID" type="m2m:nodeID" />
<!-- TODO: This attribute is called hostedCSEID in TS-0004, but is called hostedCSELink in TS-0001 -->
<xs:element name="hostedCSEID" type="m2m:ID" minOccurs="0" />
<!-- Child Resources -->
<xs:choice minOccurs="0" maxOccurs="1">
<xs:element name="childResource" type="m2m:childResourceRef" minOccurs="1" maxOccurs="unbounded" />
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element ref="m2m:memory" />
<xs:element ref="m2m:battery" />
<xs:element ref="m2m:areaNwkInfo" />
<xs:element ref="m2m:areaNwkDeviceInfo" />
<xs:element ref="m2m:firmware" />
<xs:element ref="m2m:software" />
<xs:element ref="m2m:deviceInfo" />
<xs:element ref="m2m:deviceCapability" />
<xs:element ref="m2m:reboot" />
<xs:element ref="m2m:eventLog" />
<xs:element ref="m2m:cmdhPolicy" />
<xs:element ref="m2m:activeCmdhPolicy" />
<xs:element ref="m2m:subscription" />
</xs:choice>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="nodeAnnc">
<xs:complexType>
<xs:complexContent>
<!-- Inherit common attributes for announceable Resources -->
<xs:extension base="m2m:announceableResource">
<!-- Resource Specific Attributes -->
<xs:sequence>
<xs:element name="nodeID" type="m2m:nodeID" />
<!-- TODO: This attribute is called hostedCSEID in TS-0004, but is called hostedCSELink in TS-0001 -->
<xs:element name="hostedCSEID" type="m2m:ID" minOccurs="0" />
<!-- Child Resources -->
<xs:choice minOccurs="0" maxOccurs="1">
<xs:element name="childResource" type="m2m:childResourceRef" minOccurs="1" maxOccurs="unbounded" />
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element ref="m2m:memoryAnnc" />
<xs:element ref="m2m:batteryAnnc" />
<xs:element ref="m2m:areaNwkInfoAnnc" />
<xs:element ref="m2m:areaNwkDeviceInfoAnnc" />
<xs:element ref="m2m:firmwareAnnc" />
<xs:element ref="m2m:softwareAnnc" />
<xs:element ref="m2m:deviceInfoAnnc" />
<xs:element ref="m2m:deviceCapabilityAnnc" />
<xs:element ref="m2m:rebootAnnc" />
<xs:element ref="m2m:eventLogAnnc" />
<xs:element ref="m2m:cmdhPolicyAnnc" />
<xs:element ref="m2m:activeCmdhPolicyAnnc" />
<xs:element ref="m2m:subscription" />
</xs:choice>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:schema>
README.md
+ 6
− 0
View file @ da1fc57b
...@@ -11,6 +11,7 @@ General ...@@ -11,6 +11,7 @@ General
How should virtual resources be represented? According to TS-0001 they are Child Resources, but they have a well-defined name which makes them look a bit like attributes that have a URI type. Presumably we are supposed to return these URIs if rc includes "child-resource-references" but not if it asks for just "attributes" or for "child-resources". So one interpretation is that we don't show them in the schemas at all, and they are just returned via the childResourceRef mechanism (this would mean we would need to add values for the virtual resources to the resourceType enumeration). The alternative is to represent them as explicit named elements in the schema (like we do for attributes) and return their values that way (when rc permits this). How should virtual resources be represented? According to TS-0001 they are Child Resources, but they have a well-defined name which makes them look a bit like attributes that have a URI type. Presumably we are supposed to return these URIs if rc includes "child-resource-references" but not if it asks for just "attributes" or for "child-resources". So one interpretation is that we don't show them in the schemas at all, and they are just returned via the childResourceRef mechanism (this would mean we would need to add values for the virtual resources to the resourceType enumeration). The alternative is to represent them as explicit named elements in the schema (like we do for attributes) and return their values that way (when rc permits this).
There are a few places where attributes are defined as xs:string. If these are human readable - e.g. groupName - that's fine (though it raises a question of whether they should carry the xml:lang attribute). In some cases - e.g. contentType or locationStatus - it seems that the value is meant to be machine readable, but we don't enumerate (or even define) the allowable values for them. There are a few places where attributes are defined as xs:string. If these are human readable - e.g. groupName - that's fine (though it raises a question of whether they should carry the xml:lang attribute). In some cases - e.g. contentType or locationStatus - it seems that the value is meant to be machine readable, but we don't enumerate (or even define) the allowable values for them.
Showing the cardinality of child resources is tricky for resource types where the cardinality varies by child resource. It's easy to do if we make them a sequence, but that forces a particular order. If we want to allow them to appear in any order, we have to use a repeated choice, which makes it hard to force a minOccurs of 1 or a maxOccurs of 1 on any of the of the child resources - they all become [0..n]
\<accessControlPolicy\> \<accessControlPolicy\>
...@@ -41,6 +42,11 @@ General ...@@ -41,6 +42,11 @@ General
The order in which the attributes appear is different between TS-0001 and TS-0004 (also TS-0004 should say creator not Creator) The order in which the attributes appear is different between TS-0001 and TS-0004 (also TS-0004 should say creator not Creator)
Should the element for the virtual resource be called fanOut or fanOutURI? Should the element for the virtual resource be called fanOut or fanOutURI?
\<node\>
There's an attribute which is called called hostedCSEID in TS-0004, but is called hostedCSELink in TS-0001
The cardinality of the child resources is enforced (see general comment)
\<serviceSubscribedNode\> \<serviceSubscribedNode\>
Needs to be added to TS-0004 (in place of authororizedNode) Needs to be added to TS-0004 (in place of authororizedNode)
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment