[sc34wg3] TMCL issues

[Michael Quaas]

> If you have any new issues ...
>   
Yes. I'd like to propose to simplify the internal structure of the TMCL 
schema (without changing its behavior). That means to represent all 
constraints not as topic-types but as association-types and respectivily 
all association-types the constraints are involved with, as the 
corresponding role-types. This is possible because
    a) all constraints have a connection to the constrained topic-type 
through exactly one association
    b) all these associations are binary 1-1-associations (the min and 
max cardinality equals 1 for both roles).
So a) fulfils the association pattern an b) the role pattern.

Some constraints hold additional data like min max cardinalities in 
occurrences. I suggest to represent that in a topic (having the same 
occurrences as the constraint before) which either
    a) reifies the constraint association or
    b) plays an additional role in it.

Doing so we could diminish the number of Topic Map constructs used in a 
specific schema drastically. For instance the usage of the template 
plays-role creates 1 topic, 3 associations and 6 roles. With the 
proposed solution it would be 1 topic, 1 association and 3 roles (50% 
less). Ok, as in general the number of real data is much higher than the 
number of the schema defining objects, this is not a strong argument. So 
here's a better one.

During my work on a specification for a TMCL-based user interface 
generator, I had to find out, how I get all the possible characteristics 
of a given topic-type. As I can not assume that the schema uses the 
ctm-templates, I have to go through the details. In the current draft 
the procedure to find for instance all the name-types of a topic-type 
looks like this:
    1. get the counterplayers of the constrained-topic-type association
    2. filter them by type topic-name-constraint
    3. for each of them get the counterplayers of the 
constrained-statement association.
In the proposed solution it would look like this:
    1. get all counterplayers of the topic-name-constraint. Done.
So it also reduces the complexity of the schema-queries. These are used 
frequently by the UI-generator and its data validator.

Also the ctm-schema file got now 30 lines less (don't know if that at 
countable measure) and the templates file 16 lines less then the current 
draft.
Total number of Topic Maps constructs used in the TMCL-schema:
Current draft:   T: 206,   O: 196,    A: 414,    R: 828,    Total: 1644
Proposed sol.:   T: 192,   O: 263,    A: 146,    R: 329,    Total:  930
                    -7%,     +34%,      -65%,      -60%,           -43%

Summary:
    + it doesn't change the behavior
    + it doesn't change the "API" (signature of ctm templates)
    + it reduces the complexity
    + it reduces the number of information items
    + it is (in my opinion) easier to learn
    - there are just two weeks to discuss it


Besides that I'd like to make some suggestions that might help beginners 
to learn the language.
    - rename topic-role-constraint in plays-role-constraint
    - rename association-role-constraint in has-role-constraint
    - add an constrained-associaion (after you've understood the whole 
tmcl-schema you see the advantage of using constrained-statement, but at 
the beginning it's not very intuitiv)
A more general suggestion
    - make it possible to constrain the role combinations for other then 
binary associations

Best regards,
Michael Quaas