[tmcl-wg] TMCL Requirements and Use Cases N0405rev

[Mary Nishikawa]

Thanks again Robert,

As I said before, I am commenting in detail here so that this can be 
brought to the table in Philly. I removed anything we agreed 
with  previously, or general editing comments.

>*Robert
> > >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
*Mary
> > This is how it was expressed in N0266 and I tend to agree with it.

*Robert
>N0226 says:
>   "TMCL shall permit the definition of classes of topic maps...."
>TMCLreq says:
>   "TMCL will provide a means to express constraints on classes of topic 
> maps..."
>This is NOT the same. The former is using TMCL as a means to induce an
>equivalence relation on topic maps relative to a constraint to form
>classes of map. The formulation might not be a simplest conceivable,
>though.
>The latter makes it appear as if you would apply constraints to
>classes of maps.

Agreed.

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

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

*Robert
>I thought the whole idea of the standard series is to avoid that there
>are instances out there which claim to be "Topic Maps" and are not.

OK, let's try to avoid anything that could be misconstrued.

This is what we have now:
TMCL will provide a means to express constraints on classes of topic maps 
conforming to the Data Model [DM] for ISO/IEC 13250:2002 Topic Maps [13250].

How about this?

TMCL will provide a means to express constraints on  topic map properties 
described in the Data Model [DM] for ISO/IEC 13250:2002 Topic Maps [13250].

I think that I want to forget about using Topic Map "constructs" -- these 
are defined as being  the information items, and I am now thinking that it 
should be removed from the definitions. I think that topic map properties 
would suffice, and then everyone can go the  DM reference and find out what 
they are.

> > 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?
>
>Depends on my mother (seriously :-), she plans to visit me in Dec)

OK, this is going to be left on the table for discussion.


> > >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.
>
>Maybe, but the strawman (I have reservations against adhoc-ish languages)
>should not be used for illustration. The requirements should be 
>self-contained,
>IMHO.
>
> > >       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.
>
>Well, this is not (directly) a 'political' issue, much here has to do
>with maths and logic. A constraint is a statement (logical expression).
>This statement can be evaluated with a particular Topic Map at hand.

This not  political. I only mean that this is an item for discussion.
I have been hanging out with engineers too long.  An *issue*  is defined as 
an item for discussion :)

>Either this gives true or false. (We do not want undecidable here).
>
>If you take two such statements C1 and C2 you can evaluate both against
>the Topic Map and they will give their respective results. If you 'AND'
>these then you have combined them.
>
>BUT: If there is no model around (no map to test against), then the
>schema/constraint-merging software will only see the schema. And to test
>whether they are compatible/subsuming/conflicting heavily depends on the
>expressitivity of TMCL.
>
>So to make a requirement like the above is determining already the
>expressitivity level. We can do that, but then it must be more conscious
>and not so implicit.

For discussion.

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

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

*Robert
>"Instructions in the map" must be supported by XTM!!! Not sure whether
>this is on the agenda.

Let's put it on the agenda then :)

>And the whole business around XML application servers has shown us that
>coding XSLT sheets into XML documents is a major pain.
>
>*Robert
> > >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.
>
>This is now R13.
>
>I faintly remember that the versioning discussion already passed with
>TMs. There was a fraction which - rightfully probably - claimed that
>with TMs you can build you own versioning system if you want that.
>So, the conclusion, why hard-code this into XTM.
>
>If we already ask (R9) that schemas can be reified (why not), then why
>suddenly a versioning for this?

Item for discussion

> > >       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?
>
>If it says:
>
>   "This should include features for relating revisions to prior versions..."
>
>then "relating" could mean that we define "how the change has
>happened".  And that would mean "updating of a schema". I think it is
>too early for that.

For discussion,

> > >ad R10: sub[ ]classing [and] transitivity
> >
> > subclassing transitivity? I do not get you here. I think that these are
> > separate.

Agreed.

>---------------------------------
> > >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.
>
> From what I found from Paul Prescod (as he is cited in this context):
>
>    <quote>
>    Introspection
>           The ability to read in a schema description or create one from
>           scratch, manipulate it, access all useful information and
>           write it back out.
>    </quote>
>
>But the goal is 'user interface generation' and 'validation'. My point
>is that this MAY have something to do with introspection, but also MAY
>not. How a language/implementation achieves this, should not matter as
>long as it does.

OK, I think I am beginning to agree with you here.
This needs confirmation from others at the meeting.

>If - for instance - an editor sees a constraint
>
>   forall topics of type author
>     => there must be a URL, u1, u2 or u3
>
>and a topic of class poet (which in turn subclasses author) is going
>to be created, then the editor may use some subsumption technique to
>derive that the above constraint is relevant and will then
>
>
>   forall topics of type poet (and poet subclasses author)
>     => there must be a URL, u2, u3 or u4
>
>then it may use some subsumption technique to suggest the the URL is
>u2 or u3.
>
>A conventional programmer might try to solve this with inspection. Someone
>familiar with logic might break the constraints down to clauses and do
>resolution.
>
>---------------------------------
> > >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.
>
>But it maybe says, what we want. And not more and not less.

For discussion.

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

For discussion.

> > >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.
>
>This is now R23.
>
>On one of the greek islands some thousands of years ago people built a
>long tunnel. To speed up the work they attacked the work from both
>sides of the mountain. Of course, measurement at that time was not
>precise, so the two tunnels missed each other. They solved it with a
>lot of digging.
>
>Not sure, why the story popped up in my mind :-)

No sure either, but a nice example :)

*Mary
> > Who said we were leaving datatypes out of the language?
> > See requirement R12 v 1.17
>
>    R16. Data types
>
>    TMCL will not specify its own set of basic data types.

*Robert
>This means it is NOT specified WITHIN the language. The only thing which
>may happen is that we borrow/steal data types from the given sources.
>
>If so, then we also have to live with =, >, <, ... defined there. (Well,
>we could redefine them, but why should we?)

OK, I agree with you here. We need to massage the prose.

>*Robert
> > >ad SR8: "...introduction of 'virtual' ......"
> > >
> > >        This is rather cryptic and - if fully explained - would justify
> > >its own bullet.
>
>?????

Robert this is your statement, and I still do not know what you mean :)

"TMCL may allow the introduction of "virtual" (extended) constructs which 
can be reused in defining new validation rules (a kind of "virtual" 
relations/associations)."

Virtual = extended constructs

We need to clarify what this means, or if you want to give it a shot :))

> > >ad SR8: "....named complex conditions...."
> > >
> > >        I can only speculate what this means.
> >
> > Ok, so can you elaborate on this to make it clearer :)
>
>Clever :-))

I'm waiting :)

Thanks,
Mary