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

[Dan Corwin]

* Robert Barta

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

Would this work okay?

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

> 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 agree 100%.  And I secretly hope you construct a compiler for AsTMa!,
so it can be retained as the source code.

Then we can declare TMCL to be its byte-code output, stored away in
type-tagged <resourceData>, and refocus on a portable run-time module.

That should give us the best of both worlds, and (I hope) it also 
exposes your pattern matching logic as a handy new run-time utility.

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

Actually, I worry about keeping them distinct.  They can get separated,
then evolve out of sync.  But issue this is easy to resolve.

If TMCL compiles a source into XTM schema, roughly as above, then your 
output file can stay separate, and I can merge mine into my TM.

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

I would try to test with *no* iterating - see testProp().  The code
just uses the engine API and its given args to look up what it needs.

A TMCL compiler creating XTM schema can be coded in Perl and run across
the net.  But if its run-time support module was also in Perl, then my
Java app would be calling Perl code on its local host.  That interface 
would make me very nervous.  At best, it is *not* platform portable.

So I think we must require TMCL's interpreter to run in the engine 
process for speed and transportability.  If we require its schema file 
to be in XTM, that is easy.  So I'd insist on both, were it up to me.

> I do not see a limitation yet in terms of use cases. Maybe you mean
> here usage scenarios.

To me they mean the same.  Explain the difference; I'll adjust.  :->

Dan