Invariant vs static schema in RM-ODP???

[John Chludzinski]

Whereas invariant schema express relationships which "must always be
true, for all valid behavior of the system", static schema express
relationships which "must be true at a single point in time". I
assume that a place, i.e. an interface, can be equivalent to a "single
point in time"; hence, a static schema expression can be associated
with an interface in the form of a pre-condition or post-condition.
Correct?


---John Chludzinski

[Edward A. Feustel]

Post by John Chludzinski
Whereas invariant schema express relationships which "must always be
true, for all valid behavior of the system", static schema express
relationships which "must be true at a single point in time". I
assume that a place, i.e. an interface, can be equivalent to a "single
point in time"; hence, a static schema expression can be associated
with an interface in the form of a pre-condition or post-condition.
Correct?
---John Chludzinski

The word place gives me pause. I don't think that an interface in the
computational view
is associated with a place necessarily. There may be multiple instances of
the realization of
that interface at different places. Now if the interface can have multiple
instances, they might not all have the same "static schema" at the same
time, e.g., there can be race conditions in an
engineering view of a distributed system. Now if an engineering object is
bound to another
engineering object and that binding is maintained across the instant of time
discussed, then
for a static schema, perhaps we have a valid pre- and post- condition. If
the binding is broken and resumed, it is not clear to me that we must.
Things get really tricky if we have failures or if "time passes
while we are checkpointed".
It strikes me that invariant is correctly perceived, but that static refers
to an information object which between its creation and deletion does not
change as opposed to dynamic that refers to an information object which
between its creation and deletion may change.

Ed Feustel

[John Chludzinski]

Ed,

First, thanks!

By equating place (location) with a "point in time", what I'd hoped to
convey is the idea that whenever execution reached an invocation of
that interface (no matter where [possibly multiple locations] or how
many times that may occur), the predicate (pre-/post-condition) would
apply. But this begins to sound strikingly like dynamic schema (a
"specification of the allowable state changes").

Am I beginning to blur the distinction?

---John Chludzinski

Post by Edward A. Feustel

Post by John Chludzinski
Whereas invariant schema express relationships which "must always be
true, for all valid behavior of the system", static schema express
relationships which "must be true at a single point in time". I
assume that a place, i.e. an interface, can be equivalent to a "single
point in time"; hence, a static schema expression can be associated
with an interface in the form of a pre-condition or post-condition.
Correct?
---John Chludzinski

The word place gives me pause. I don't think that an interface in the
computational view
is associated with a place necessarily. There may be multiple instances of
the realization of
that interface at different places. Now if the interface can have multiple
instances, they might not all have the same "static schema" at the same
time, e.g., there can be race conditions in an
engineering view of a distributed system. Now if an engineering object is
bound to another
engineering object and that binding is maintained across the instant of time
discussed, then
for a static schema, perhaps we have a valid pre- and post- condition. If
the binding is broken and resumed, it is not clear to me that we must.
Things get really tricky if we have failures or if "time passes
while we are checkpointed".
It strikes me that invariant is correctly perceived, but that static refers
to an information object which between its creation and deletion does not
change as opposed to dynamic that refers to an information object which
between its creation and deletion may change.
Ed Feustel