[sc34wg3] TMCL Comments (Part I)

[Robert Barta]

Hi,


Here is a quick write-up of my pre-Leipzig TMCL notes:

================================================================

3.1 I would say here that CTM and CTM templating is used and would
move the "Additional TMCL templates" (sect 5) here. That looks lost
where it is now.

That "RolePlayerConstraint" hangs in the air. Not defined? Maybe
plays-role from 4.4.18 is meant? But then the cardmin/max is missing.

Have an example of the use here?

3.2 typo?  semantics ... is defined using TMQL [expressions]

----------------------

4 TMCL

# second para repeats what has been said already

All constraint types [defined] follow...   # are there others?

# style: REP intended to be used

3. para uses two different font sizes?

and the header TMCL is alone on the previous page. let me guess: text
processing ala M$?

--------------------

4.1 # I suggest to rewrite it as follows:

(Define elsewhere: A schema contains any number of constraints.)
Define: tmcl:schema:

A topic map $M can be validated against a given schema $S. If it
validates, then the association

  tmcl:is-valid-for (tm:topicmap: $M, tmcl:schema: $S)

can be asserted.         # define tmcl:is-valid-for

Every constraint within a schema is of a particular constraint type,
characterizing an expectation on the map being validated. Every such
constraint type has an occurrence of type //tmcl:validation// in the
scope //tmql:tmql//. The value of this occurrence is a valid TMQL
expression which will be evaluated on validation time against the map
to be validated.

That TMQL expression reports whether the constraint is violated or
not.  On violation, the constraint is the result; on validation
success the result is empty.

The above association between $M and $S is then assertable, iff

  for $c in $S // tmcl:constraint
  where
     tmcl:evaluate ($M, $c)
  return
      $c

returns an empty list, i.e. reports no violations. Hereby the function
//tmcl:evaluate// takes the original map and the constraint itself as
parameter. It will derive the validation expression itself via the
type of the constraint

   $c >> types / tmcl:validation

Note: Validation expressions are attached to the constraint type, not
to individual constraints.

Then it will evaluate that TMQL expression after binding

  - $c to a TMQL variable $this
  - $M to a TMQL variable %_ (default map)

Note: The variable $this is necessary to access the specifics of that
constraint.

----------

The generic CARDMIN/MAX stuff is - I think - not necessary as every
TMQL expression can (should) test whether a card* part exists and only
test it then. So no need to invent defaults, or MAX_INT workarounds.

----------

4.4.2 # As example for a global constraint

Yada yada a bit of more descriptive text what it is good for...
.....


.... then the definition

tmcl:topic-type-constraint ako tmcl:constraint
tmcl:validation : """
   return
      if ( uniq ( // tm:topic >> types) -- // tmcl:topic-type )
         $this
""" @ tmql:tmql .


IF(!) there is an example, then it should be enlightening. The

   ttc isa topic-type-constraint

does not fall in this class. In fact, that is misleading as this
ttc MUST ALWAYS be part of a schema, otherwise the

   car isa tmcl:topic-type .
   dog isa tmcl:topic-type .

are NEVER honored.

Same with 4.4.3, 4.4.4, 4.4.5, 4.4.6

----------------

4.4.1  # this sort of repeats what 4.3.6 says? => ditch 4.4.1 ?

-----------------


4.4.7 typo: infer[r]ed

2. para, 2. sentence is not a sentence?

The repetition in prose what CTM could express is awkward. I would
generally (applies to other constraint types too) suggest:

  1. What is this good for?

  2. Defined CTM fragment.

  2a. If there are certain constraints on these CTM things, _that_
     can (probably has to) given in prose.

  3. Create a good example. The following

   c isa abstract-topic-type-constraint

     is not. And the association has roles and players wrong. If
     it is an association. Could be a template invocation, too, but
     then ...

Specification of that constraint is straightforward:

  abstract-topic-type-constraint ako constraint
  validation: """
      %pragma taxonometry tm:intransitive
      for $type in $this <-> applies-to  # this is a weird assoc type, btw
      where
          $type >> instances
      return
          $this
  """

The assoc in the isAbstract template is wrong.

Would not the example be better

isAbstract (vehicle) .

?

=================================================================

Hope that I get to the rest soon.

\rho