Rev 0.5 of XEP-0323

xep-0323.xml

@@ -30,19 +30,40 @@
       <uri>http://www.linkedin.com/in/peterwaher</uri>
     </author>
     <revision>
-			<version>0.3</version>
+      <version>0.5</version>
-			<date>2014-04-07</date>
+      <date>2015-03-02</date>
       <initials>pw</initials>
       <remark>
-				<p>Updated IQ-error stanzas for <link url='#readoutrejected'>readout rejections</link> to make them compliant with RFC-6120.</p>
+        <p>
-				<p>The element <strong>rejected</strong> is no longer used and has been removed.</p>
+          Added '<strong>cancel</strong>' and '<strong>cancelled</strong>' elements to the XML schema.
+          These elements where previously available in <link url='#cancelreadout'>use cases</link>, but not documented in the XML schema.
+        </p>
+      </remark>
+    </revision>
+    <revision>
+      <version>0.4</version>
+      <date>2014-03-31</date>
+      <initials>pw</initials>
+      <remark>
+        <p>
+          Updated IQ-error stanzas for <link url='#readoutrejected'>readout rejections</link> to make them compliant with RFC-6120.
+        </p>
+        <p>
+          The element <strong>rejected</strong> is no longer used and has been removed.
+        </p>
         <p>
           Harmonization of data types between XEP-0323 and XEP-0325. This has resulted in the addition of the following new field types: <strong>date</strong>,
           <strong>int</strong>, <strong>long</strong> and <strong>time</strong>. The <strong>timeSpan</strong> type has been renamed <strong>duration</strong>.
         </p>
-				<p>The term Field Status Value has been renamed <link url='#fieldqosvalues'>Field Quality of Service Value</link>, to make it clearer.</p>
+        <p>
-				<p>Added a <link url='#fieldqosvalues'>inProgress</link> field quality of service value.</p>
+          The term Field Status Value has been renamed <link url='#fieldqosvalues'>Field Quality of Service Value</link>, to make it clearer.
-				<p>Added a section giving an example of the <link url='#estimatesvsreadouts'>difference between estimates and normally read values</link>.</p>
+        </p>
+        <p>
+          Added a <link url='#fieldqosvalues'>inProgress</link> field quality of service value.
+        </p>
+        <p>
+          Added a section giving an example of the <link url='#estimatesvsreadouts'>difference between estimates and normally read values</link>.
+        </p>
         <p>
           A new field attribute named <link url='#control'>writable</link> has been added. It can be used to inform clients that the corresponding value can be controlled
           using XEP-0325.
@@ -51,11 +72,18 @@
       </remark>
     </revision>
     <revision>
-			<version>0.2</version>
+      <version>0.3</version>
-			<date>2014-03-10</date>
+      <date>2014-02-17</date>
       <initials>pw</initials>
       <remark>
         <p>Changed the id attrobutes of IQ stanzas, to highlight they are different from sequence numbers used in requests.</p>
+      </remark>
+    </revision>
+    <revision>
+      <version>0.2</version>
+      <date>2013-05-07</date>
+      <initials>pw</initials>
+      <remark>
         <p>Fixed links to documents with new numbers.</p>
         <p>Changed namespace urn:xmpp:sn to urn:xmpp:iot:sensordata</p>
       </remark>
@@ -105,8 +133,12 @@
       <remark>
         <p>Corrected some errors in XML examples.</p>
         <p>English corrected.</p>
-				<p>Added <strong>errors</strong> elements to the <strong>rejected</strong> element.</p>
+        <p>
-				<p>Added <strong>cancel</strong> command with corresponding <strong>cancelled</strong> response.</p>
+          Added <strong>errors</strong> elements to the <strong>rejected</strong> element.
+        </p>
+        <p>
+          Added <strong>cancel</strong> command with corresponding <strong>cancelled</strong> response.
+        </p>
       </remark>
     </revision>
     <revision>
@@ -130,7 +162,7 @@
     <p>
       Sensor networks contains many different architectures and use cases. For this reason, the sensor network standards have been divided into multiple XEPs according to the following table:
     </p>
-		<table caption='Sensor Network XEPs'>
+    <table caption='Internet of Things XEPs'>
       <tr>
         <th>XEP</th>
         <th>Description</th>
@@ -139,10 +171,6 @@
         <td>xep-0000-IoT-BatteryPoweredSensors</td>
         <td>Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network.</td>
       </tr>
-			<tr>
-				<td>xep-0000-IoT-Discovery</td>
-				<td>Defines the peculiars of sensor discovery in sensor networks. Apart from discovering sensors by JID, it also defines how to discover sensors based on location, etc.</td>
-			</tr>
       <tr>
         <td>xep-0000-IoT-Events</td>
         <td>Defines how sensors send events, how event subscription, hysteresis levels, etc., are configured.</td>
@@ -172,8 +200,10 @@
       </tr>
       <tr>
         <td>XEP-0323</td>
-				<td>This specification. Provides the underlying architecture, basic operations and data structures for sensor data communication over XMPP networks. 
+        <td>
-				It includes a hardware abstraction model, removing any technical detail implemented in underlying technologies. This XEP is used by all other sensor network XEPs.</td>
+          This specification. Provides the underlying architecture, basic operations and data structures for sensor data communication over XMPP networks.
+          It includes a hardware abstraction model, removing any technical detail implemented in underlying technologies. This XEP is used by all other sensor network XEPs.
+        </td>
       </tr>
       <tr>
         <td>XEP-0324</td>
@@ -195,6 +225,10 @@
         <td>XEP-0336</td>
         <td>Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;.</td>
       </tr>
+      <tr>
+        <td>XEP-0347</td>
+        <td>Defines the peculiars of sensor discovery in sensor networks. Apart from discovering sensors by JID, it also defines how to discover sensors based on location, etc.</td>
+      </tr>
     </table>
   </section1>
   <section1 topic='Glossary' anchor='glossary'>
@@ -214,8 +248,10 @@
       </di>
       <di>
         <dt>Field</dt>
-				<dd>One item of sensor data. Contains information about: Node, Field Name, Value, Precision, Unit, Value Type, Status, Timestamp, Localization information, etc.
+        <dd>
-				Fields should be unique within the triple (Node ID, Field Name, Timestamp).</dd>
+          One item of sensor data. Contains information about: Node, Field Name, Value, Precision, Unit, Value Type, Status, Timestamp, Localization information, etc.
+          Fields should be unique within the triple (Node ID, Field Name, Timestamp).
+        </dd>
       </di>
       <di>
         <dt>Field Name</dt>
@@ -250,17 +286,22 @@
         <dd>
           Graphs contain nodes and edges between nodes. In Internet of Things, sensors, actuators, meters, devices, gateways, etc., are often depicted as nodes whereas links between sensors (friendships)
           are depicted as edges. In abstract terms, it's easier to talk about a Node, rather than list different possible node types (sensors, actuators, meters, devices, gateways, etc.).
-					Each Node has a Node ID.</dd>
+          Each Node has a Node ID.
+        </dd>
       </di>
       <di>
         <dt>Node ID</dt>
-				<dd>An ID uniquely identifying a node within its corresponding context. If a globally unique ID is desired, an architecture should be used using a universally accepted 
+        <dd>
-				ID scheme.</dd>
+          An ID uniquely identifying a node within its corresponding context. If a globally unique ID is desired, an architecture should be used using a universally accepted
+          ID scheme.
+        </dd>
       </di>
       <di>
         <dt>Parameter</dt>
-				<dd>Readable and/or writable property on a node/device. The XEP-0326 &xep0326; deals with reading and writing parameters
+        <dd>
-				on nodes/devices. Fields are not parameters, and parameters are not fields.</dd>
+          Readable and/or writable property on a node/device. The XEP-0326 &xep0326; deals with reading and writing parameters
+          on nodes/devices. Fields are not parameters, and parameters are not fields.
+        </dd>
       </di>
       <di>
         <dt>Peak Value</dt>
@@ -268,14 +309,18 @@
       </di>
       <di>
         <dt>Precision</dt>
-				<dd>In physics, precision determines the number of digits of precision. In sensor networks however, this definition is not easily applicable. Instead, precision
+        <dd>
+          In physics, precision determines the number of digits of precision. In sensor networks however, this definition is not easily applicable. Instead, precision
           determines, for example, the number of decimals of precision, or power of precision. Example: 123.200 MWh contains 3 decimals of precision. All entities parsing and
-				delivering field information in sensor networks should always retain the number of decimals in a message.</dd>
+          delivering field information in sensor networks should always retain the number of decimals in a message.
+        </dd>
       </di>
       <di>
         <dt>Sensor</dt>
-				<dd>Device measuring at least one digital value (0 or 1) or analog value (value with precision and physical unit). Examples: Temperature sensor, pressure sensor, etc.
+        <dd>
-				Sensor values are reported as fields during read-out. Each sensor has a unique Node ID.</dd>
+          Device measuring at least one digital value (0 or 1) or analog value (value with precision and physical unit). Examples: Temperature sensor, pressure sensor, etc.
+          Sensor values are reported as fields during read-out. Each sensor has a unique Node ID.
+        </dd>
       </di>
       <di>
         <dt>SN</dt>
@@ -420,7 +465,7 @@
     </p>
     <section2 topic='Request Read-out of momentary values' anchor='readmomentary'>
       <p>
-				The client that wishes to receive momentary values from the sensor initiates the request using the <strong>req</strong> request sent to the device.
+        The client that wishes to receive momentary values from the sensor initiates the request using the <strong>req</strong> element sent to the device.
       </p>
       <example caption='Read-out request of momentary values from a device'>
         <![CDATA[
@@ -782,8 +827,10 @@
   </query>
 </iq>]]>
     </example>
-		<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined 
+    <p>
-		in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
+      In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined
+      in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
+    </p>
   </section1>
   <section1 topic='Implementation Notes' anchor='impl'>
     <section2 topic='String lengths' anchor='stringlengths'>
@@ -792,9 +839,11 @@
         affected negatively by this for two reasons:
       </p>
       <ul>
-				<li>For sensors with limited memory, or where package size is important, &xep0322; is supposed to be used. 
+        <li>
+          For sensors with limited memory, or where package size is important, &xep0322; is supposed to be used.
           EXI compresses strings as normalized index values, making the string appear only once in the packet. Therefore, shortening string length doesn't affect packet
-				size much. Element and attribute names in known namespaces are furthermore only encoded by index in schema, not by name.</li>
+          size much. Element and attribute names in known namespaces are furthermore only encoded by index in schema, not by name.
+        </li>
         <li>If limited memory or package size is not a consideration, readability and ease of implementation is preferred to short messages.</li>
       </ul>
     </section2>
@@ -1429,6 +1478,18 @@
         </xs:complexType>
     </xs:element>
  
+    <xs:element name='cancel'>
+        <xs:complexType>
+            <xs:attribute name='seqnr' type='xs:int' use='required'/>
+        </xs:complexType>
+    </xs:element>
+ 
+    <xs:element name='cancelled'>
+        <xs:complexType>
+            <xs:attribute name='seqnr' type='xs:int' use='required'/>
+        </xs:complexType>
+    </xs:element>
+ 
     <xs:element name='fields'>
         <xs:complexType>
             <xs:sequence minOccurs='0' maxOccurs='unbounded'>
@@ -1633,6 +1694,6 @@
     </ul>
   </section1>
   <section1 topic='Acknowledgements' anchor='ack'>
-		<p>Thanks to Joachim Lindborg, Karin Forsell, Tina Beckman, Kevin Smith and Tobias Markmann for all valuable feedback.</p>
+    <p>Thanks to Flemon Ghobrial, Joachim Lindborg, Karin Forsell, Tina Beckman, Kevin Smith and Tobias Markmann for all valuable feedback.</p>
   </section1>
 </xep>