[tmcl-wg] TMCL Requirements and Use Cases N0405rev

[Robert Barta]

On Sat, Nov 01, 2003 at 04:22:06PM +0900, Mary Nishikawa wrote:
> The TMCL Requirements and Use Cases was published Oct 31, 2003 and can be 
> found here:
> 
> http://www.y12,doe.gov/sgml/sc34/document/0405rev.htm

Mary, Graham,

I see that a lot of work has been invested. Having implemented both AsTMa! and
AsTMa?  I have now a clearer view what might be relevant. Here are the things I
found in version 1.17:

<> means suggested additions, [] means deletion, s/// substitution in texts

-----------------

overall) structure is good, one may wonder whether the E-Sell scenario could
         be closer to the begin. Makes it maybe more understandable.

ad 1.  s/2001-10-5/2001-10-05/

ad 2.1. Why "on classes of ..." ?

       Constraints apply to TM instances. In that they _define/induce_
       classes (a set of TMs which adhere to a constraint), but that does not
       seem too relevant here.

ad 2.1. Why stress "...topic maps conforming to DM". Are there others?

ad 2.1. ....schema information...

       Concept 'schema' is not defined yet.

ad 2.2. ....Free Ranging Patterns....constructs which can be ...dispersed throughout a map.

       I do not believe you can give me an example :-)

       And are 'patterns' already constraints?

       Suggest: "General constraints which do not constrain the
                 existence or form of individual topic map constructs, but
                 dependencies between constructs in the whole map."

       Not much better, probably.

ad R2: ....topic map construct that breaks a TMCL constraint.

       If a constraint can apply to a whole map then this is too specific.

ad R3: a) It should be made clear that you use 'merge' synonymous to 'compose' and that synonymous
          to 'AND'.

       b) What this req means is that  you force the language to be so expressive that
          for any constraints C1, C2 it is decidable whether there
          is a model (map) for 'C1 AND C2' or not.

          That is ok, I think. The problem with the formulation is
          that it sounds as if it should be decidable in 'real-time'
          be the "merging application". This could be a problem.

ad R4: ... resources that <can> have ....

ad R7: What does it mean to "explicitely commit"? Do you mean "conform"?

ad R9: I have major objections against this. I do not think it is appropriate for a(ny) language
       to define it's versioning. There are so many versioning systems out there that it seems a fallacy
       to move this into a language. TMCL statements are in text documents and for these versioning is trivial.

       I only would agree with this if TMs by themselves had a version concept.

       And: With such a mechanism we already move into the TM UPDATE discussion. Not sure
       whether we want this now.

ad R10: sub[ ]classing [and] transitivity

ad R11: ....identifiers and roles....

       What 'identifiers' do you mean here? Probably not topic IDs.

ad R14: s/structures/constructs/

ad R17: ditto

ad R19: ditto

ad R20: Once a language has a formal syntax it is by definition 'introspective'. You probably want
        to say that

          "TMCL should have a semantics in such way that is not only allows the unambiguous decision whether
           a given map conforms to a given schema, but also allows applications to interpret TMCL statements
           'constructively' and 'incrementally' as it is necessary for user interface generators and TM authoring
           environments."

ad R23: Why must there be a model for the 'internal representation' of constraints?

        And what is the 'behavior of validation'?

ad R24: I am not sure whether this arbitrary distinction should be here. Why not

        "TMCL MAY define different conformance levels."

ad SR1: s/by/for/

ad SRn: ditto

ad SR1: the phrase "allow valid combinations.." would apply to all others as well.

ad SR8: If we keep the data types out of the language, then =, <>, <, etc on
        numerics cannot be part of the language. We can maybe use 'string' as
        the only type and define ops on this type.

ad SR8: "...introduction of 'virtual' ......"

        This is rather cryptic and - if fully explained - would justify its own bullet.

ad SR8: "....named complex conditions...."

        I can only speculate what this means.

ad SR9, SR10: I have the impression that this mixes up a couple of things, although I cannot
        pinpoint all of them.

        The 'permissive validation' seems to be an interpretation of a TMCL statement:

           "A TMCL statement can be interpreted either 'permissive' or 'restrictive'. In
           the former interpretation a map or (part of a map) may have additional constructs
           while still be conformant to the TMCL statement.

           A restrictive interpretation of a statement means that map may only hold the constructs
           which are prescribed in the statement. Any other constructs will make the map non-conformant."

        Is it this (liberal <=> fascist, minimal <=> maximal) what you want to express?

ad SR9: The second bullet we already covered with the others, I guess.

ad 4.1 I have not worked through this section yet, but spotted a few typos.

ad 4.2.1 comment:

        "....TMCL schema allows to present....what is entered already.... and missing"

        TMCL cannot do that, applications using TMCL might be able to do that.

ad 4.2.1 suggestion make bullets : GU1, GU2, ....?

ad 4.2: Should the title be "Generic Use Cases"?

ad 5.1: "human friendly....XML" sounds like an oxymoron :-)

ad 5.2: "..standardized representation as TM..." 

        I wonder for what this is good. Should then also a TMQL statement be
        represented as a TM? And why not?

ad 5.3: "...use of TMQL...."

        s/identity/identify/

        This is a _bigger_ thing. Maybe worth to elaborate on.

ad 5.4: "TMCL should support ....authored by humans".

        Why this restriction? Not that I would expect many aliens to use TM, but....

ad 5.5: s/This/These/

ad 5.5: 'virtual topic map' are not defined.

ad 6.  I found about 60 typos and missing articles here. There is also some
       inconsistency in the argumentation which should be fixed in the final doc.

       Sometimes paragraphs appear in bold.

       We should make a clear distinction between the mapping of the schema and the
       mapping of the data.

       The update process is rather underdefined.

       The references to 'inline occurrences' are AsTMa-ish and should be removed.

       The argumentation at the end is unclear (at least to me).

ad 8.  s/XTM syntax specification, and/XTM syntax specification and/

That's all.

\rho