[tmcl-wg] Re: Updates [was: Another TMCL use case]

[Dan Corwin]

This extends discussion of use case A and example 1b within:

  http://www.isotopicmaps.org/pipermail/tmcl-wg/2003-May/000090.html

Can TMCL be used to *prevent* invalid updates, instead of just 
detecting them later?  If so, we need a companion to use case A, 
which I once phrased (rather badly) as:

> > Case B) This involves a requirement that *all* topics used as
> > types, before such batch commands process them, *must* somehow
> > predeclare *in their TM* a set of constraints that limits the
> > characteristics of their instances, and restricts the changes
> > any batch command can make to them.

Said in simpler terms, while operating as in Use case A, TMCL 
should be able to block all changes *unless licensed*:

   If a map's schema fails to say which legal values a String has
   in some occurrence, then TMCL should treat it as immutable.

   And if an association role fails to define what players it can 
   accept, then TMCL should let no role players be added/removed.

Use case B seems needed if use case A is to perform "strictly".
I see these two cases as bound fairly tightly, such as in this 
potential logic for testing proposed updates:

testProp(Topic T, Occurrence X, String S) throws Exception
{ 
  testsPassed = 0;    // this variable supports use case B

  if topic T is an instance 
  {
    1. get the "instanceCriteria" in its class
    2. if one is found                           // use case A
       { 
         a. apply it to topic T *ASSUMING X HAS VALUE S*
         b. if the criteria fails, raise a case-A exception
         c. testsPassed = testsPassed + 1;      // for case B  
       }
  }
  ... other possibly applicable constraints

  if testsPassed == 0                            // use case B
  {
    1. get specialCaseExceptions                 // an option
    2. if none, raise a case-B exception         // normal logic
  }
}

In my imagination, the code above would raise an exception if 
given any *proposed* fact, F, of this form:

   F = "T holds occurrence X, to be modified to hold S"

   Its case-A code complains if F fails to pass a known test
   Its case-B code complains unless F actually passes tests

This could raise an exception, for instance, if S were null
and X was of type "model", since making that change would 
delete the occurrence's Resource, and that would contradict 
the embedded "instanceCriteria" of example 1b.

It could also raise an exception if nothing had been said of 
the occurrence in the embedded schema, under the theory that 
if such changes were expected, something would have been said.
(This theory must be optional to allow authoring vrs updating).

* Robert Barta

> You are now asking whether a constraint (set) C can be checked against
> TM and F independently? Sure, but in general it DOES NOT hold:
> 
>    C |= TM + F      <=>    C |= TM  and   C |= F
> 
> where x |= y means "constraint x validates map y"

I know there are pitfalls of logic here, but I would not demand 
rigor in this use case, nor would end users.  If limitations of
testProp() and code like it were clearly explained, they could
still be heuristics very helpful in catching edit errors.

Such limits seem more than balanced by the more fine grained
testing such rules allow, and by the fact that no data within
a loaded map must be modified to test them.

This means that related change-events need never be spuriously 
triggered.  It also lets TMCL itself support new TM applications,
such as validating updates to an independent database that was
being modeled by a TM's embedded schema.

Overall for updates, I see a two-part TMCL mechanism extending
a compliant TM engine.  Configured by embedded constraints that
an end user might adjust, it can decide *before* each update is
made if such updates were licensed by TMCL constraints:

  * if so, but specific details would be out of spec, complain
  * if not, TMCL should then offer these two options (at least):

    Case A) the unconstrained value means any change is legal
    Case B) it instead seems unexpected, so complain about it

In case B, TMCL has to let a user with special update rights 
(like an admin or an ontology author) change a TM unimpeded.
Everyone else would change it only in the ways pre-approved 
by its author in an embedded schema.  And they might perhaps 
be further fine-tuned by adjusting scopes for the occurrences 
that hold the stored constraints.

To me, all this seems more compelling than batch-validation.
That is why I think "update" use cases should become part of
TMCL requirements.

Cheers,
Dan Corwin