[tmcl-wg] Another TMCL use case

[Robert Barta]

On Thu, May 15, 2003 at 12:40:21PM -0400, Dan Corwin wrote:
> > I would believe that a TM?L works against a "TM model". This would
> > imply that - as long as you can map your data into the TM paradigm -
> > you could use TM?L.
> 
> 1) The draft requirements say TMCL works against SAM, so the 
> TM must be loaded to use TMCL.

It says "TMCL shall be specified in terms of SAM" but that does not
mean that it will be necessarily be implemented atop of it.

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.


> They say less about the set of constraints.  Must a TMCL schema be
> applied *as a whole* to a TM, or can its constraints be used more
> selectively?

I do not see a difference: Given a schema S with constraints A, B, C:

+-- S -------
|
|  A
|
|  B
|
|  C
+------------

No one can stop you to pick A and C via introspection of the schema
and build with it S'

+-- S' ------
|
|  A
|
|  C
+------------

> 2) If some new fact F would violate TMCL constraints, must F be
> already recorded within the loaded TM before TMCL can discover that
> violation, or can F be presented independently to TMCL?

To understand this correctly: Your situation is to have a map TM and
separately from that another map containing information F.

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"

> 3) Either way, parts of the loaded TM must be read to make 
> such a validation.  The draft requirements speak of selectors.
> Is TMQL usage required here, or can TMCL use other selectors
> to specify the targets of constraint criteria?

Whether TMQL is used for TMCL or the other way round (my opinion
as this works perfectly fine with AsTMa!?) is not yet decided on.

> > They way I understand your API is that it adds value to a low level
> > API a TM?L implementation may give you.
> 
> Actually, my API as stated would add value to the one published 
> for TM4J.  I cannot rely on TM?L, as its specs and APIs seem so 
> vague as to be still many months from solidifying.
> 
> > I do not think that we have discussed APIs how to use TM?L yet.
> 
> If we did, I believe it would help advance the requirements spec.

Maybe, although starting with APIs too early blurs sometimes the
bigger picture. I also do not think that the specifics of the API
would have a major impact on what you develop today.

In the case of AsTMa! this will probably be along the lines:

   my $tm = new XTM (...."file:test.xtm"...);
   my $c  = new XTM (...."file:constraint.atm"...);

   warn "damn damn damn" unless $c->validates ($tm);

or similar for checking individual violations of the constraint.

> Questions 1-3 are API issues, and APIs do interact heavily with 
> expected use cases for TMCL as a whole.  I'm not talking details 
> of particular selectors or criteria, but rather a broad brush view 
> of how - and especially when -  TMCL might be applicable.

I hope the above may give you an idea. Quite some variations are
conceivable, but you can easily simulate that now.

\rho