[tmcl-wg] Re: TMCL UseCase and Requirements

[Robert Barta]

On Tue, Jun 03, 2003 at 10:17:55AM +0200, Graham Moore wrote:
> I've managed finally to reorganise the req document.  (please find attached)

Graham,

My comments are below.

> Having looked through N0408, Topic Map Constraint Language Use
> Cases, I would propose that sections 3.1 -> 3.5 get added under
> section 2.

We are talking about merging

   http://zope.it.bond.edu.au/research/borgtom/projects/astma2prolog/tmcl_usecase

into your document? If so, then I would have seen 3.1 - 3.3 as part
(via merging :-) of your section 4.

> and that section 4. gets added under section 3 above.

Erica's "4.  Usage Scenarios" would then go under 5 "General Use
Cases". Maybe I am mixing up documents.

> 1.3. Lars Marius perhaps we could give CVS access to Robert and
> Erica?

I think this may make only sense if the overall structure is settled.

> 3. I need to chase people up to tell them what they are meant to be
> preparing for montreal.

I will most probably be NOT present in Montreal.

----

General:

  - Whenever there is a document mentioned (like N259 or N226), there could
    go a link.

  - I would remove names of individuals. Things should be judged on their own
    merits.

2.1: Why "classes of topic maps"?

    It is true that a constraint (or a set of constraints) induces an
    equivalence class on the set of topic maps. But why should
    constraints only be on classes of TMs?

2.1: ....a topic map can be said to be conforming within a topic map....

    This is probably not what you mean.

2.1: The concept "schema"...how does it relate to constraint? 

    Maybe have in a preamble that "set of constraints is synonymous
    for "schema"?

2.1: delete "more intuitive"? Does not really add value, I think.


2.1: ..that, outlines

     delete comma, delete 's'

2.1: ..., provides....

     delete 's'



2.2: "'s and ,'s are mixed rather freely, some are missing

2.2: Maybe move "Topic Map constructs" upfront and equate it with
     "topic map information items".

2.2: A constraint also enables extensions to the model ....

     I do not understand this. Which model?


2.2: ...or merged sets of topic maps.

     I would suggest that a constraint ALWAYS is evaluated on a
     consolidated, i.e. merged topic map. We do not have a model for a
     "set of topic maps not yet merged", so defining what constraints
     should do then is impossible.

2.2: "Schema introspection".....schema.....

     Is this not trivially satisfied as long as the schema is
     represented as a bit or character string?

     If it remains, let's make a literature reference to where Paul
     has defined this.

2.2: Remove ""'s around the concepts or otherwise change the
     rendering.



3.1: ...requirements. It ....

     To what does 'it' refer to?

3.1: ....[N249]. It ...

     ditto


3.2.1: What about merging this minisection with 3.2.4 ? Especially as
     XTM is mentioned.

3.2.3.1: what are now "schema constructs"?

3.2.3.1: ...in the map, i.e. only topics of types...

     I think you try to specify here more than possible or
     necessary. What this section seems to be about is that there is a
     special use of a constraint (set):

     We have "a map satisfies a constraint": This means that the
     constraint is evaluated and either gives a non-empty result or
     not. And then we have "A map _minimally_ satisfies a constraint"
     if it satisfies the constraint and is minimal in the sense that
     no more topics and/or associations can be taken from the map
     without violating the constraint.

3.2.3.2: ...relaxation...

     In which sense relax?

3.2.5: s/may/MAY/  ?

     suggest: ...may make use of _parts of_ TMQL....

     suggest: ...to be constrained. Alternatively, TMQL may ...

     s/identity/identify/

     suggest: Goal is avoid overlap between the languages.

     ...with the task of TMQL ....being the generation....

        This does not quite come out quite right.

3.3: Ad note: should support the validation of ...authored by humans.

     What is so special about these topic maps?

4:  suggest: ...based on topic map constructs.

    s/Names/names/

    s/Identities/identities/

4.* The phrase "allow combinations of the above" is valid actually
    throughout. Maybe factor that out.

4.1.2:  What is a 'notation'?

4.4: ...should allow different combinations _of_ such ...

4.4: s/us//

4.4: The last three paragraphs - starting with TMCL may allow" are
    misplaced.

5: ....high level than those ....

5.1: The use case would definitely be more understandable if it had
     more prose and us a specific _use case_. Now it has general
     requirements like "more intuitive.." (we had that already), "user
     interface generation", "editing".

     If these are so general, then we should put them into a separate
     section like "goals" or "intended use/overview".

     But the specific use case should be more elaborated on. Maybe in
     a similar detail as Erica's case.

5.1: s/equivalent technologies/related technologies/

5.1: The TMCL should support introspection.

     - if it is a separate use case, then it should be a separate section

     - it should be described more thoroughly

     - there is a "generate user interfaces" how does it related to the above?

     - storage optimization is an EXCELLENT point, but it is a _separate_ use case, IMHO.

     - query optimization is another

5.2: Merging

     Another very good use case, but not well described as it is
     now. A link to the outside should eventually be avoided.

6.1* suggest: completely remove the sectioning and make the text prose for section 6.

6.1.7: If a test suite is out of scope then I would put this sentence
     into a "Related/Future Work" section. Maybe into a
     Conclusion/Summary.

     s/schema/schemas/  ?? What is the plural of schema?

7. ...specification, and TMQL, .....

     remove comma?

\rho