[tmcl-wg] TMCL Requirements and Use Cases N0405rev
Robert Barta
tmcl-wg@isotopicmaps.org
Wed, 05 Nov 2003 14:13:49 +1000
Mary, Graham,
---------------------------------
On Mon, Nov 03, 2003 at 12:47:16AM +0900, Mary Nishikawa wrote:
> >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.
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.
---------------------------------
> >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.
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.
---------------------------------
> >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?
Yup.
---------------------------------
> 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)
---------------------------------
> >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.
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.
---------------------------------
> >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.
"Instructions in the map" must be supported by XTM!!! Not sure whether
this is on the agenda.
And the whole business around XML application servers has shown us that
coding XSLT sheets into XML documents is a major pain.
---------------------------------
> >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?
---------------------------------
> > 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.
---------------------------------
> >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 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.
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.
---------------------------------
> >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.
---------------------------------
> >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 :-)
---------------------------------
> >ad SR1: s/by/for/
>
> I don't get what you want
The sections are all titled 'Constraints by <this and that>'.
I was just wondering whether this should be
'Constraints for <this and that>'
---------------------------------
> >ad SR1: the phrase "allow valid combinations.." would apply to all others
> >as well.
>
> ?
In the itemize list under SR1 there is now:
- 'allow valid combinations of the above'
In all the other SRxs the 'combination of the above' could be added as well,
isn't it?
---------------------------------
> >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
R16. Data types
TMCL will not specify its own set of basic data types.
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?)
---------------------------------
> >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 :)
Clever :-))
---------------------------------
> >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.
Yup.
---------------------------------
> >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.
This is just a request for rewording.
---------------------------------
> >ad 4.2.1 suggestion make bullets : GU1, GU2, ....?
> >
> >ad 4.2: Should the title be "Generic Use Cases"?
>
> Why?
It is now called 'General', but since the use case is applicable to
ALL TMs I thought 'Generic' more appropriate.
------------------------------------
> >ad 5.1: "human friendly....XML" sounds like an oxymoron :-)
>
> You have said this before -- this is political, and we know where you stand
> :)
I stumbled over this yesterday:
http://www.cs.uu.nl/people/franka/xml-treatise
:-)
------------------------------------
> >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 :)
Yes, the current version is better, but I still miss a couple
of articles. For instance:
'Customer name is represented as....'
I would rephrase as
'The customer's name can be represented as ..., the address, ....'
Or:
'These constraints for a topic map... represented in Topic Map Constraint Language'.
"the" is missing or simply "TMCL" is used.
Or:
"Adding <a> new category in topic map..."
Or:
"E-Sell Corp.'s product database is currently in <a> relational database."
Tiny things like these.
---------------------------------
> Not sure what you mean by the "inconsistency in the argumentation"
A database person would argue "and why is it ugly" to model
this in a RDB? That did not quite come out for me.
And why/how is TMCL used to facilitate merging?
Thx for the good work!
\rho