[tmcl-wg] Template and Expression layers: both needed for tmcl?

[Dmitry]

[Mary Nishikawa]
Sent: Saturday, March 22, 2003 7:19 AM
Subject: [tmcl-wg] Template and Expression layers: both needed for tmcl?

> *Robert Barta
>
> commenting on section 1.1.2.1:
> http://www.isotopicmaps.org/tmcl/requirements/
>
> I do see the question whether there should be a
>
>    TL (template layer), and a
>    EL (expression  layer)
>
> independent whether the can be morphed into XML or not.
>
> *MN
> Comments Please!!! thanks


I am a supporter of TMCL with two layers: Class Template Layer and
Constraint Expression Layer (actually, with three layers, I will try to
clarify this below).

I think both layers can be implemented using XML but probably with two
different sublanguages. Main reason is that these layers have different
purposes, different requirements. And I am not sure that XML is "the best"
approach for Constraint Expressions Layer.

>From my perspective Class Template Layer is targeted primarily for "smart"
viewers and "smart" editors. This layer supports only basic validation.
"Smart" viewers allow presenting information about topic based on class
template(s). User can see what kind of information (names, associations,
occurrences) is expected and what is really presented in topic map. "Smart"
editors use class templates to simplify entering information by limiting
range of possible values and suggesting "reasonable" options.

Class template defines in fact list of questions relevant to each instance
of this class. Class template also provides "guidelines" for answering these
questions.

If we have XML-based language for Class Template Layer we can stimulate
creating topic map "smart" editors/viewers. Solution developers will not
depend on proprietary language specific APIs. It will be possible to create
something like "XMLSpy" or "InfoPath" for topic maps.

Constraint Expression Layer, from my perspective, is targeted for topic map
validation.   This layer allows expressing various constraints. It can
include such constructs as "exists", "forall", "and", "or", "not", "implies"
in different combinations. The same constraint can target multiple topics
and topic attributes and associations. Class Template Layer, of course, can
be expressed using expression layer (for validation or explanation
purposes). But, in principle, Class Template Layer does not require full
Constraint Expression Layer engine. Class Template Layer validation can be
implemented with simpler tools than full scale validation engine.  I see
Constraint   Expression Layer engine as "pluggable" module.

In my previous postings I suggested third layer:  "Constraint Template
 Layer".  This suggestion was a reflection of the idea that Class Template
in fact is not just "one big constraint". Class Template usually consists of
multiple combined (merged) constraints.  The idea is that, firstly, we
should look at "basic" constraints. We also should provide rules which
define how these "basic" constraints are combined into Class Templates.

For example, if we have class C1 and class C2 with templates and we define
for class C3 that C3 is subclass of C1 and C3 is subclass of C2, how we can
get template for class C3. If we need to specify additional constraint for
class C3 how we can define that this constraint is not inherited from C2 or
C1 or other superclasses.

With Constraint Template Layer answer is quite simple. Class Templates are
"virtual". Constraint engine in fact can create class templates "on the fly"
from "basic" constraints.

For example, if user specifies in "smart" editor that "john is Perl-hacker"
and "john is Java-hacker", editor can ask constraint engine to return class
template for class "Perl-hacker and Java-hacker". Based on this "combined"
template editor can create form with fields for "Favorite Perl Book" and
"Favorite Java Book" which are mapped to corresponding occurrences.

I see Constraint Template Layer as a "demarcation" line between Class
Template Layer and Constraint Expression Layer. It does not necessarily
require a specific "language". It is a conceptual layer that helps (at least
for me) to understand better different usage scenarios and various issues
regarding constraint infrastructure.

>From my perspective Constraint Template Layer defines closed (for specific
version of TMCL) list of constraint templates. Class Template Layer must
allow representing all these constraint types. This list essentially should
be based on list from initial TMCL requirements document.

Constraint Template Layer also defines how constraints are propagated
through superclass-subclass hierarchy, how constraints from multiple
superclasses are merged, how additional constraints can be applied in
subclass, how constraints from topics can be merged with constraints from
names, occurrences and associations. Each Constraint Template also has
corresponding validation rule which allow evaluating constraint on existing
set of instances (can be implemented directly at procedural level).

Constraint Template Layer also defines how relevant constraints can be
combined into "one document" - Class Template.

That's what I have so far.

Dmitry