[tmcl-wg] Describe two or three layers?

[Mary Nishikawa]

Dmitry,

Thanks. Your proposal was one of the reasons I brought this up.

So we now have two proposals:

Two layers  -- Robert Barta
Class Template Layer
Expressions Layer


Three layers -- Dmitry

Class Template Layer
Constraint Expressions Layer
Constraint Template Layer


Since Dmitry is adding one more layer in addition to the ones proposed by 
Robert, I suggest to keep it in the requirements document  and discuss it 
in London.

I will use what Dmitry has written here to describe this third layer, for now.

Comments anyone?


FYI -- I will be submitting the draft formally to ISO over the weekend so I 
would appreciate comments by the end of this week or sooner if possible, Thanks!


Cheers,
Mary




At 23:25 03/03/26 -0500, Dmitry wrote:
>[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
>
>
>_______________________________________________
>tmcl-wg mailing list
>tmcl-wg@isotopicmaps.org
>http://www.isotopicmaps.org/mailman/listinfo/tmcl-wg