[tmcl-wg] Functional Requirements and Syntax Proposals: Please Submit

[Robert Barta]

On Thu, Feb 20, 2003 at 11:19:00PM -0500, Dmitry wrote:
> The main idea of "Schema or Class template" layer is that we compress and
> package basic constraints related to class  into one "schema document". 
...
> It is easy to add very complicated constraints which are out of scope of
> "templates" at this layer. Probably, it is possible to interpret and check
> "rich" constraints on specific set of instances (what do we do about
> negation and "open world" assumption?). But I think this layer does not
> really help topic map editors to create/modify topics. It can help mostly
> with advanced validation.

I completely agree here, with one smaller variation:

It is correct that for editing applications templates are easier in
the first run to generate forms or some other 'guided' authoring
support.

BUT, templates are a dead end. This means that strategically these
applications will have to live with the limitations of templates.
Which could be fine.

On the other hand, it should be possible to look at constraint
expressions and derive from them editing support. For example:

forall [ $x (composer) ]
  => exists [ $x
              bn @ en : * ]
     and
     exists [ (authors)
              opus : *
              author: $x ]

Could be simply seen as rule that - once the user creates a composer
topic - a form has to make sure that there is an english basename and
that there is a field for opus. This is pattern matching on the
structure of constraints. Using this notation, though, allows the
editor to become more and more sophisticated and also cover rather
application specific constraints.

\rho