Re: application facing lifecycle, data and interaction model for things

Hi Dave,

the API work is important -- it needs to mirror the abstractions
provided by the protocol.  We can work on these being good, or we can
let them being diluted by trying to accommodate a soup of gateways.

> I believe that we agree about the ability to model things in terms of
> software objects with properties, actions and events. 

I just sent a message to this list that points out that the event
abstraction is confusing.  Several different things are being called
"event" that should not be handled by the same mechanism.  Choosing the
wrong word for a set of concepts vaguely related sometimes makes people
think that they have a single concept at hand.  Not so.

(I didn't send the message pointing out that the action abstraction is
also too broad, but I made the point repeatedly in Sophia Antipolis.)

> In Montreal,  I talked about formalising the type system for things and
> building upon the solid body of programming language theory.  [...]

OK, so you want to create another data modeling language.
https://xkcd.com/927/ and all that.

I don't blame you, we just went through the same exercise.

The data modeling languages that are out there don't really cope with
JSON-based data models well.  W3C of course has WSD, but that has
exactly this problem.  It also has other problems.  The most useful data
modeling language for XML is Relax-NG, which also finally has broken
with the weird idea that a modeling language for X needs to be expressed
in X (leading to Relax-NG compact).

So for data models that are using the general idea of JSON, we did CDDL
as a synthesis of ABNF and Relax-NG
(https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl).
IETF also has YANG (RFC 6020 and
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-12), which is
for data at rest, not for data in flight.  This still has a bit of XML
cruft in it.  There are many people who want to use YANG models for IoT,
so it is likely that this modeling language will stay relevant in this
space.

The Web architecture does not have a data modeling language, instead it
has an interesting abstraction called media types.  These were borrowed
from E-Mail (an architecture that is close to the "event" abstraction
that many people have).

> I further see the need for having things and streams as first class
> types. 

I cannot send a thing along in a message, so I don't know what that
would mean.  (A reference to a thing can be, and we have URIs for that
in the Web.)

"Stream" seems to be a term that is mixing up event sequences, time
series, and general notifiable properties.  It is more about interaction
than about data modeling.  We probably need to understand the boundary
here better.

> Borrowing from the Web, an event has a name and carries a single value,
> which could be atomic or compound. There is a standard way to register
> or unregister a handler for a given event name.

Oh, there is an implicit assumption here that the originator of an event
sequence has the responsibility to send it to you (the "handler").
Atom is a different design, even moderately successful (RFC 4287).

> I soon realised that with things as properties, it is necessary to allow
> for cyclic dependencies between things and a mechanism to avoid
> deadlocks when starting up a set of interdependent things. 

The Web has been very successful in navigating the CAP problem by
avoiding the urge for C.  We may want to learn from that.

I'm going to stop here, but you may get what I'm after here:
A design from scratch is going to repeat all the mistakes that have been
made in distributed systems and programming environments and then some.
 I'd rather start with the Web and evolve from there.

Grüße, Carsten

Received on Thursday, 28 April 2016 21:45:37 UTC