[tmcl-wg] Feedback on requirements 2003-Apr-04

[Robert Barta]

Hi Mary,

Here are some comments, some of them being just a repetition what I
have sent earlier.

2.1:

   This document will define the requirements that we expect the language will provide.

   TMCL will not "provide requirements" later.

   Suggest rephrasing:

      This document will define requirements on a future TMCL. The
      requirements herein shall not be interpreted in a 'closed' way;
      the working group may at any time decide that particular
      features in this document may be dropped or that other are to
      be brought in.

   Suggest moving the sentence:

      TMCL is to be developed....

   to a different place. It does not quite fit in here.

2.2 Comes late as we use shall/may... already in 2.1.

   Suggest: Move.

2.2: Maybe replace 'information items' with topic map constructs? It is
    used later and more words in a definition not always help.

2.2: "Constraint reification" is ability to represent a constraint as topics.

    Topics or topic?

2.3 Maybe consider to move this to end?

3.2.4. Why does the syntax appear here? Seems to be misplaced.

3.3.1. Where is 'validation exception' defined?

    Is this an exception raised by a validator or are these exception
    to validation?

    Suggest to add it to the definitions.

3.3.1.1 and 3.3.1.2 : Maybe drop 'strict and loose' as the common terminology is
    definitely 'open and closed'.

    In any case, this is NOT a language issue, but how the validator
    is applied on a map: If I ask "does this map validate against this
    constraint" then the validator may return "yes, but there are other
    components in the map NOT following this. If you are happy with this
    then you interpreted it "open". If not, then you wanted it 'closed'.

    It is still the same constraint in the same language.

3.3.1.2 the Note would well fit into the scope section.

3.3.1.3 I wonder whether it should be that detailed. Someone could defer
    from this that we are looking for a fully-fledge FOL (first order logic).

    Also the part about numeric data is EXTREMELY dangerous. Without
    a well defined typing infrastructure this opens up a can of worm.

    Suggest to reduce it a bit to quantifiers and logical operations.

3.3.2

    I find this somehow misleading. A particular topic map "does not
    have a schema to define it's consistency". What consistency means
    is highly depending on the context, so I see this simply as (a) I
    have a map, (b) I have a set of constraints and (c) either this
    validates or not.

    One and the same map could be perfectly ok for me and useless to
    you.

    Suggest: drop.
    Alternative: elaborate on it in the scope section.

3.3.4

    Is this important? What is the idea behind this?

Thanks for your consideration.

\rho