#191 refine from Thing

There are many Properties in a Scenario that require the prescence of a Type for a property and the scenario to be valid. At the moment the Scenario is regarded as invalid when types are missing. In the future it may be regarded as incomplete, but in essence the type is left blank.

In the spirit of SRT's principle of incremental elaboration of the scenario and choreography I propose that the initial value of a type in a scenario is always set to "Thing". Thing is the supreme supertype. This way "Thing" is always available in the drop-down property selection.

The major benefit is that this gradual refinement of type is consistent with the SRT method. A secondary benefit is it may make implementing the editor simpler.

The point is where we have a requirement for a type we can always be certain it is a Thing. The modelling is merely a refinement of Thing.

[kohei]

Logged In: YES
user_id=1274231
Originator: NO

Today I had a long workshop.

I agree refinement is an important idea for conversational/
choreographical modelling.

The following is a note regardless of what is the best for the
editor but a general point.

As I wrote I agree with this (including it's compatible with
SRT method) noting that: if there are

(1) version 0
(2) version 1
...

of choreographies (conversation models/protocols) where we
incrementally refine message types then

--- a receiver of a message as conforming to (1) will still
conform to (2)
--- a sender of a message conforming to (2) will conform to
(1) but not the other way round generally

The safest way is to always check against the latest version
of choreography (conversation model).

If somebody is using an older version then if others are using
the same version it would be all right: a local montor st
always check if messages conform to the latest version (or
the latest among all versions participants are using: I think
there should be a mechanism of sharing this information).

kohei