[tmcl-wg] Selectors [was: Another TMCL use case]

[Dan Corwin]

Thank you for your feedback, Robert.  Your response 
was exceptionally clear.  To do it justice, I will 
split own my reply into multiple parts.

* Robert Barta
 
> Consider a constraint like
> 
>   forall $c [ * (car) ]
>     => exists $c [ oc (model) : * ]
> 
> which says "all car topics must have a specific occurrence". An
> optimizing validator will need to have an index of all car topics.
> SAM does not mention indexes.

To help convey my point, I will first put this constraint in 
another format, closer to that I ultimately advocate.  

Example 1a. - Instead of two lines in a flat file, it is 
now moved into an XTM document, easier for programs to 
manipulate.  Selector and restriction are now labeled:

<topic id="example1a">
 <instanceOf><topicRef xlink:href="#constraint" /></instanceOf>
 <occurrence>
   <instanceOf><topicRef xlink:href="#selector" /></instanceOf>
   <resourceData>forall $c [ * (car) ]</resourceData>
  <occurrence>
 <occurrence>
   <instanceOf><topicRef xlink:href="#restriction" /></instanceOf>
   <resourceData>exists $c [ oc (model) : * ]</resourceData>
  <occurrence>
     
Example 1b. - Here is another format that I like even better.
It is even more compact, and more powerful and flexible, as 
it is now embedded *within* the map being constrained:

<topic id="car">
 <occurrence>
   <instanceOf>
     <topicRef xlink:href="#instanceCriteria" />
   </instanceOf>
   <resourceData>[ oc (model) : * ]</resourceData>
  <occurrence>

The compactness arises in part because I have replaced the 
logical selector of example 1a with storage directly in the
"car" topic.  This has (or could have) similar semantics.

I also replaced the "restriction" with "instanceCriteria".
This gives me as a TM programmer more freedom to adjust the 
rules under which its resourceData is processed.  Example 
1a gave me only the rules for "exists" - a simple option.
Now I can invent several minor variations and extensions.

If TMCL confines itself to a (limited) use case of batch-mode
-topic-map-validation-via-a-schema", the extra flexibility will
have no obvious benefit.  But I have not lost anything so far, 
as the above would still work with this modified algorithm, now 
running natively inside my Java TM engine:

globallyValidate(OutputStream theComplaintList)
{ 
  For all topics in the loaded map
  {
     For each topic T which is an instance
     {
       1. get the "instanceCriteria" in its class
       2. if one is found
       {
         a. apply it to topic T
         b. if the criteria fails, dump out a complaint
       } 
     }
     ... other stored topic constraints
  }
  For all associations in the loaded map
  {
     For each association A which has a type topic
     {
       1. get the "associationCriteria" in this topic
       2. if one is found
       {
         a. apply it to A
         b. if the criteria fails, dump out a complaint
       } 
     }
     ... other stored association constraints
   }
}

Compare this directly with your bundled equivalent:

>    my $tm = new XTM (...."file:test.xtm"...);
>    my $c  = new XTM (...."file:constraint.atm"...);
> 
>    warn "damn damn damn" unless $c->validates ($tm);

.. and several differences at once appear, even though it
does the same thing:

  * my code is faster - no longer in a separate process
  * the schema file has been replaced by storage rules

There are also changes (or expansions, if you prefer) to
definitions of the constraint language which being used:

  RESTRICTIONS: their nature has changed incrementally
  SELECTORS: their nature has changed greatly

The handling of local variable(s) in both constructs is
a powerful part of AsTMa! and I do not want to mess them
up, just extend them further than "forall" and "exists",
which seem tailored too much to a single use case.

This pattern-matching logic you have built is extremely
powerful, and it can be re-applied in a number of useful
ways.  Your AsTMa language family amply demonstrates some,
but with embedded selectors I think TMCL can do even more 
with them.

I'll cover some ideas in other emails, as this one is already
too long.

Cheers,
Dan Corwin