[tmcl-wg] Another TMCL use case

Dan Corwin tmcl-wg@isotopicmaps.org
Thu, 15 May 2003 12:40:21 -0400


* Dan Corwin

> > My WORDS command language uses topic maps for storage, and
> > changes them under interactive inputs or batch files.
..
> > I hope to use TMCL in this system, so WORDS is another use
> > case for it.  But I cannot tell from current requirements
> > if TMCL will work fast and flexibly enough for editing,
> > or if the data to validate must already be within a TM.

* Robert Barta
> 
> Yes, no, maybe. :-)
> 
> 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.  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?

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?

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?

> > Unsure on such issues, and on when TMCL might appear, I went
> > ahead on a private WORDS spec and coding plan to incrementally
> > pre-validate requested TM updates.  Here's what emerged:
> >
> >   http://www.lexikos.com/words/constraints.htm
> >
> > This design gives a coder's view of a constraint language.
> > It may be instructive, or it may need some rethinking.
> 
> 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.

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.

> Can you give me/us a bit more background information how you plan to
> use TM?L with WORDS? Maybe I can get someone to build a nice use case
> around it, maybe you want to write up one yourself?

Today, I cannot really *plan* using TM?L at all within WORDS, 
as I have no idea (yet) whether any API for TM?L might allow 
their close interaction.  I merely remain hopeful.

I can and do assume TMCL, in some independent process, will 
help confirm all those details of a TM someone has had the 
foresight and diligence to pre-declare within a schema file,
and that such processes, by being used, will help to reduce 
errors in (some of) the XTM files I import or create.

That is nice, but still weak - not a compelling benefit.

The use cases I am proposing be added would benefit WORDS 
(which resembles what you describe as AsTMa+) and all the 
future applications that mutate (versus read) TMs.  They 
do get considerably more specific and concrete:

Case A) This involves a batch file of simple commands run as a 
script to mutate a TM in limited ways.  I want the script to stop
work with a good explanation *before* it violates any constraint,
yet not slow down obnoxiously (over x 3) due to the added burden 
of constraint validation.

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.

The constraint system I have described for WORDS should handle 
both use cases.  Should TMCL also be able do so?  If not, why?

Best Regards,
Dan Corwin