[tmcl-wg] TMCL Requirements and Use Cases N0405rev

[Mary Nishikawa]

Robert,

Thanks for your detailed feedback as always.  Just so this doesn't totally 
confuse everyone, the draft that Robert is commenting on is the one on 
http://www.isotopicmaps.org/tmcl/requirements.html  version 1.17

>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:

For the meeting in Philadelphia please refer to the draft here:
http://www.y12.doe.gov/sgml/sc34/document/0405rev.htm This is version 1.22.

I will update the web page ASAP to avoid this confusion. The requirments 
had been moved around a bit so the numbers  will not match up.

I will add Robert's comments to the next working draft. It would be good to 
get as many comments as possible before the meeting in December. I will do 
my commenting here too, since I will not be in Philadelphia.

><> 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.

This document is for you and everyone else who will work on creating the 
TMCL. It is particularly important that we all agree on requirements, so I 
really wonder if this is necessary. You would like to make this more 
understandable to whom?


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

OK.


>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.

This is how it was expressed in N0266 and I tend to agree with it. Yes, I 
would envision one schema that could be used on certain classes of topic 
maps. This is emphasizing the group (set) instead of topic maps as 
instances with one tmcl schema. This is not essential,  to say one way or 
the other here, I agree with you here, but I would rather leave it in. It 
is interesting to me that you comment on this.

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

Yes, I think there are, and for these, the tmcl will not be relevant. I 
think that it is important to state this.

>ad 2.1. ....schema information...
>
>        Concept 'schema' is not defined yet.

Ok, we can take this out here if we want to be really rigorous.
  Is the definition, TMCL Schema that appears in 2.2 OK with you?

>ad 2.2. ....Free Ranging Patterns....constructs which can be ...dispersed 
>throughout a map.
>
>        I do not believe you can give me an example :-)


"Free Ranging Patterns" are constraints that apply to constructs that can 
be arbitrarily dispersed throughout a topic map.
I think that this should be reworded to Free-ranging constraints.

So the constraints are on the patterns and/or constructs.


"R21 Free-ranging constraints
The language must allow for topic map constraints to apply to several 
disjoint topic map structures, i.e., TMCL will not just restrict the 
properties of a topic of a given class, or the role types of a given 
association type."

I imagined several topic maps that had properties in common that needed 
constraining, but they were not strictly contained within a given class or 
type -- I was under the impression that this has to do with fine grain 
properties -- such as constraints related to datatyping, but I could be 
wrong. I think you have some other idea, so this needs some clarification.


It seems that we need to clarify what "disjoint topic map structures" means.


>        And are 'patterns' already constraints?


"Free Ranging Patterns" are constraints that apply to constructs that can 
be arbitrarily dispersed throughout a topic map.

Yes, this can be clarified, I think. We have free ranging patterns and 
then speak about free ranging constraints -- I think this needs to be 
changed to "free ranging constraints" in the definition.  We also need to 
clarify what the patterns are.


>       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.

Can you explain yourself here :)  Let's put this on the table for 
Philadelphia. Will you be there?


>ad R2: ....topic map construct that breaks a TMCL constraint.
>
>        If a constraint can apply to a whole map then this is too specific.

I don't understand you here. I think this needs to be illustrated through 
the strawman.


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

OK :)

>        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.

Sounds like an issue  for Philadelphia.


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

I think that this needs to be worked on. This requirement is a "should," 
then what are schemas that cannot have their own resources?

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

I don't think that  it means "conform." It is  saying that    topicmapY 
is explicitly committed to schemaX. In other words, there are 
instructions  in the topic map to use  schemaZ in topic mapY as you would 
specify  xsl stylesheetZ  in XML fileY.

Graham, please confirm.


>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.

Well, maybe they should :)
Another fun thing to discuss.


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

Don't remember this. Can you refresh my memory?

>ad R10: sub[ ]classing [and] transitivity

subclassing transitivity? I do not get you here. I think that these are separate.

We also need to be consistent with terminology:
sub class, sub-class, or subclass, well, we had better make sure that we 
are using the same one everywhere in all our standards.
What do you expect from an Englishman and American working on this :)

>ad R11: ....identifiers and roles....
>
>  What 'identifiers' do you mean here? Probably not topic IDs.

No, not topic IDs.


>ad R14: s/structures/constructs/

OK.


>ad R17: ditto

OK


>ad R19: ditto

OK


>ad R20: Once a language has a formal syntax it is by definition 
>'introspective'.

No, this is not what the requirement means.


R20. Schema introspection
The language must be constructed in such a way that it is possible to 
introspect any given schema for the purpose of user interface creation or 
automated semantic processing.


>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."

Sorry, this makes it more complicated than it should be. Can somebody 
give an example?

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

The reason is given in 5 Design Goals. See version 1.22.

>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."

We are trying to get more concrete so that we can actually begin to write 
the language. Graham is coming up with these twoand will describe it in 
the strawman. It is hard to begin writing about a language if we go back 
to these "may" statments.


>ad SR1: s/by/for/

I don't get what you want


>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.

Who said we were leaving datatypes out of the language?
See requirement R12 v 1.17


>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.

Ok, so can you elaborate on this to make it clearer :)


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

These two are important and should be looked at more carefully at the 
meeting, I agree.
They are now SR8 and SR9 in v 1.22

>         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.

Hopefully they were corrected in the updated draft, but I will check again.


>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"?

Why?


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

You have said this before -- this is political, and we know where you stand :)


>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/

Already corrected, thanks.


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

Yes, I think the design goals could be elaborated on, but I would like to 
see it in the strawman, I think.


>ad 5.4: "TMCL should support ....authored by humans".
>
>         Why this restriction? Not that I would expect many aliens to 
> use TM, but....

I am not sure why this note was left. It looks a little misplaced now.

"Note: TMCL should support the validation of topic map data authored by humans."
I think this was meant to exclude some autogenerated stuff from content.


>ad 5.5: s/This/These/
>
>ad 5.5: 'virtual topic map' are not defined.


OK, we need to define "virtual topic map"


>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.

Hopefully, most of these were picked up, but it is always good to have a 
second eye :)

Not sure what you mean by the "inconsistency in the argumentation"

>        Sometimes paragraphs appear in bold.

This really needed some new headings to take the place of the bold print, 
but I left what Erica has already submitted because of lack of time.


>        We should make a clear distinction between the mapping of the 
> schema and the
>        mapping of the data.
>
>        The update process is rather underdefined.

I will leave these for Erica.


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

They were. I will check again for remnants in 1.22 anyway.


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

Erica, can you work on this?


>ad 8.  s/XTM syntax specification, and/XTM syntax specification and/
>
>That's all.
>
>\rho


Thanks again Robert.

Cheers,
Mary