Notes from meeting: Saturday 14th of May

[ferrisoxide]

Notes from meeting: Saturday 14th of May

1. Document at xpca end-points should be simple lists of resources,
e.g.

GET 192.168.0.1/index returns a list of http references, e.g.

<ol class="xpca xoxo">
<li><a href="192.168.0.1/devices">devices</a></li>
<li><a href="192.168.0.1/meta-data">about</a></li>
</ol>

Client systems can then interrogate the system further for more
details, e.g.

GET 192.168.0.1/devices returns something like

<ol class="xpca xoxo" id="devices">
<li><a href="192.168.0.1/devices/1">boiler</a></li>
<li><a href="192.168.0.1/devices/2">pump</a></li>
</ol>

Silly example, but the general idea is that the end-point is a simple
document mapping other resources in the system. By using the xoxo
microformat (http://en.wikipedia.org/wiki/XOXO) we can also present
nested resource trees (using <ol> tags with <li> elements and meta-
data (using <dl> tags) - it doesn't have to be a flat list at the end-
point.

2. Commonly supported format to be JSON, but other formats available,
e.g.

GET 192.168.0.1/index.xml => root document returns in XML format

HTML will need to be supported in most cases, but expect JSON to be
the most widely used. We want to be able to support web designers as
much as possible, so they can integrate process control data directly
into web pages without difficultly. But we also want to make the
presentation of data as lightweight as possible so it can be
implemented directly in embedded system ala RESTduino (https://
github.com/jjg/RESTduino).

Other possible protocols, specifically for compact binary
representation, are BERT (http://bert-rpc.org/) and BSON (http://
bsonspec.org/).

3. Same basic representation regardless of implementation level.

Whether we're exposing complex objects or low-level addresses, the
same basic document structure will be used. Interrogating a small
device for a list of IO points works the same way as interrogating a
SCADA-type system running a high-level model of a production line -
both end-points return a document for further traversal.

In the case of high-level SCADA a mapping will exist between the
object model and the underlying data-point model. Because they can be
represented using the same mechanism it's possible to embed the low-
level data directly into the meta-data for the high-level object.

<ol>
<li id="Boiler1">
<ol class="modus">
<li class="modbus-resources">
<ol class="modbus-coils">
<li class="modbus-coil">1<dl><dt>name</dt><dd>Heating ON</
dd></dl></li>
</ol>
</li>
</ol>
</li>
</ol>

4. End-points can be chained

With some end-points designers and engineers won't want or need to
maintain low-level data within high-level representations. Instead the
high-level document can simply refer to another end-point containing
the relevant details.

<ol>
<li id="Boiler1">
<ol class="modus">
<li class="modbus-resources">
<a href="192.168.0.6/modbus></a>
</li>
</ol>
</li>
</ol

In many cases the low-level data sources won't be exposed at all and
the mapping will occur within the end-point server. In the boiler
example above the high-level xpca document could expose a property
"Heating Element ON" without describing how the server access the
actual device information.

5. Deferred

There are many things that would be nice to have, but we have to start
somewhere and we have to start small. For now the list of deferred
concepts includes:

* Historical data access
* Commands
* Events and alerts
* Standardised meta-data (e.g. RDFa)

The priorities for all these will emerge as we start to build the
system.

6. Next steps

* RESTModbus - a reference implementation of a Modbus to REST mapping,
with xpca end-point data.
* RESTduino - get RESTduino (https://github.com/jjg/RESTduino) running
on our test gear, with a look towards providing an xpca end-point
directly from the device

[ferrisoxide]

Other things we talked about but I forgot to mention - the idea of
defining our own set of microformats, specifically for representing
process control data within web-based documents. A good place to start
will be mapping modbus resources to a microformat.

Implicit in this is a need to standardize the way we represent
microformats in JSON and other formats. We should look at already
existing ideas and solutions - e.g. http://microformats.org/wiki/json
- rather than invent our own.