[tmcl-wg] TMCL Requirements and Use Cases N0405rev
SANTOSAPUTRI, Erica
tmcl-wg@isotopicmaps.org
Mon, 3 Nov 2003 09:33:48 +1100
Mary, Robert
I'll be looking into putting more work on the usage scenarios.
As I have mentioned to Mary earlier that there will be a few more extension to the scenarios.
Please excuse the typos and grammar errors, I will re-read and minimize these errors but off course second eyes always better.
Thanks for the comments.
Regards,
Erica Santosaputri
Systems & Technology Department
Reserve Bank of Australia
Ph: (02) 9551 9546
Email: SantosaputriE@rba.gov.au
-----Original Message-----
From: Mary Nishikawa [mailto:nisikawa@fuchinobe.oilfield.slb.com]
Sent: Monday, 3 November 2003 02:47
To: rho@bigpond.net.au; tmcl-wg@isotopicmaps.org
Subject: Re: [tmcl-wg] TMCL Requirements and Use Cases N0405rev
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
_______________________________________________
tmcl-wg mailing list
tmcl-wg@isotopicmaps.org http://www.isotopicmaps.org/mailman/listinfo/tmcl-wg
*********************************************************************************
This e-mail message (along with any attachments) is intended only for the named addressee and could contain information that is confidential or privileged. If you are not the intended recipient you are notified that any dissemination, copying or use of any of the information is prohibited. Please notify us immediately by return e-mail if you are not the intended recipient and delete all copies of the original message and attachments.
This footnote also confirms that this message has been checked for computer viruses.
*********************************************************************************