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

[Robert Barta]

On Tue, May 20, 2003 at 10:14:38AM -0400, Dan Corwin wrote:
> 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.

It cannot have the same semantics as putting it into the
context of a topic you drastically reduce the expressiveness.
What about a constraint

  "for all topics which are cars and have a subject identifier
   pointing to http://...., this and that has to hold."

?

Also the word 'compact' is difficult to reproduce for everything in
XML syntax :-)

> 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.

So why do you stop here? Why is

   [ oc (model) : * ]

not also translated into XML? What if someone wants to change
something here? I always wonder why people think that XML is the only
way to induce syntax into a text stream. People have written compilers
now for 50 years and have all used parser successfully. No programmer
would appreciate a programming language coded in XML.

I also have worries coupling a constraint too tightly with a map.
Technically these things are always separate: databases and their
schema, XML and their schema, RDF documents and their schema, ...

> 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
>   }
....
> }
> 
> 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);



>   * my code is faster - no longer in a separate process

My code was not in a separate process and - given a decent
implementation - I SERIOUSLY doubt that code which iterates over all
topics just to check whether some constraint should be checked is
faster than one which implements indexes or some other way to be more
selective.

>   * the schema file has been replaced by storage rules

Hmm?

> 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.

I do not see a limitation yet in terms of use cases. Maybe you mean
here usage scenarios, but not even there I would suspect a
restriction. It is only a matter to follow the general pattern of
applying a constraint to an existing structure.

I see some things in your other mails, maybe continue the discussion
there.

\rho