<style>
td {
vertical-align: top;
}
td, th, table {
border: 1pt solid black;
}
</style>
<table cellspacing=0>
<tr>
<th>MB
<th>Clause no.
<th>Paragraph
<th>Type of comment
<th>Comment
<th>Proposed change
<th>Sec obs
<tr>
<td>NO
<td>
<td>
<td>ed
<td>"Therefore" is consistently spelled "therefor" (which has a
different meaning) throughout.
<td>Correct the spelling.
<td>
<tr>
<td>NO
<td>
<td>
<td>ed
<td>The draft has "dangling text", that is, such as clause 4, which
has text before the beginning of subclause 4.1. This is not allowed
by ISO regulations, and the document will not pass JTC scrutiny
before this is correct.
<td>Introduce a subclause "4.1 General" before the current 4.1.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>The CTM throughout is lacking the period (.) to close the topic
blocks. Without this the CTM is incorrect.
<td>Correct the CTM.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>The CTM throughout is lacking the semicolon (;) to terminate
statements.
<td>Correct the CTM.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>The schema topic which represents an entire TMCL schema has
disappeared in this version. This topic is important for being able
to attach metadata to schemas, such as name, creator, version
number, source URL, etc etc. It is also important in order to
provide an easy mechanism for detecting whether or not a given topic
map actually contains a TMCL schema.
<p>This will admittedly complicate the writing of TMCL schemas in
CTM, and so there is some cost to including this functionality.
However, this could be mitigated by defining the standard templates
in such a way that they create a single schema "behind the scenes",
such that defining a single schema in a single topic map is handled
easily. Also, the schema and connecting associations could be
made optional.
<td>Needs discussion.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>A TMCL schema for TMCL is missing. This is important because
currently the structure of TMCL schemas is only defined by example,
which is clearly not sufficient. Obviously, TMCL is not finished
yet, and so it may be more efficient to wait with creating it, but a
placeholder would help remind us that one is coming.
<td>Add annex with meta-schema, possibly placeholder.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>The naming style of topics and templates throughout alternates
between hyphen-based and dromedaryCase. The style in TMDM is
hyphen-based, and it would be best if TMCL were consistent with
that.
<td>Change identifiers to consistently use hyphen-based naming.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>The MAX_INT literal is used to represent the biggest possible
integer in order to be able to express unrestricted maximum
cardinalities while using the templates. The problem is that this is
not a legal integer literal according to XML Schema.
<p>Possible solutions:
<ul>
<li>Find some way to shoehorn MAX_INT into CTM (and XTM 1.0/2.0!).
<li>Support optional arguments in CTM templates.
<li>Introduce topics representing cardinalities and have
predefined topics for 0-1, 1-1, 0-*, and 1-*. Omit the max-card
occurrence to make the cardinality unlimited. Pass these topics to
the template instead of the integers.
<li>Define extra templates (with different names) which omit the
max cardinality argument (implicitly setting it to infinity).
</ul>
<td>Needs discussion.
<td>
<tr>
<td>NO
<td>Intro
<td>
<td>ed
<td>This introduction is too short and doesn't really do much to
introduce TMCL.
<td>Write a longer introduction.
<td>
<tr>
<td>NO
<td>Scope
<td>
<td>ed
<td>TMCL is referred to as a "data model", but strictly speaking it
is a Topic Maps vocabulary.
<td>Correct the language.
<td>
<tr>
<td>NO
<td>3
<td>
<td>ed
<td>The function notation used in 4.1 is not defined.
<td>Add a definition of this notation.
<td>
<tr>
<td>NO
<td>4
<td>2
<td>ed
<td>This text repeats statements already made.
<td>Remove paragraph.
<td>
<tr>
<td>NO
<td>4
<td>3
<td>te
<td>This text claims that the TMQL expressions giving the semantics
of the TMCL vocabulary are stored within the schema topic map.
(Clause 8 also does this.) This is highly problematic, because it
implies that users can substitute their own TMQL expressions for the
standard TMQL expressions, and thus change the meaning of the TMCL
vocabulary defined in the standard. Given that the entire point of
defining a vocabulary is that it should have the same meaning for
all, this seems wrong.
<p>Wouldn't the spec work just as well if the TMQL queries were
given in the spec only, and not repeated as part of the schema?
In fact, as far as I can tell, how validation happens is not
actually defined anywhere, and so it's not clear what happens if
these queries are changed or omitted.
<td>Change so that the queries are given in the spec only.
<td>
<tr>
<td>NO
<td>4
<td>3
<td>ed
<td>The font size is wrong in part of this paragraph. The text also
says "a entity" and fails to start a new sentence at "deemed valid
e.g. topics".
<td>Fix formatting and typos.
<td>
<tr>
<td>NO
<td>4.1
<td>2
<td>ed
<td>The variable <tt>$THIS</tt> is defined here, but the queries as
given actually use <tt>$this</tt>.
<td>Lowercase the variable name.
<td>
<tr>
<td>NO
<td>4.1
<td>3
<td>ed
<td>The text says that applications "must not permanently modify",
but surely the meaning is that they "need not permanently modify"?
That is, if they want, or if the user asked them to, surely they
can, even if the spec does not require it?
<td>Correct the wording.
<td>
<tr>
<td>NO
<td>4.1
<td>5
<td>ed
<td>The <tt>Validate</tt> function referred to here is not defined.
This leaves open the questions about the TMQL expressions defining
the semantics, and also means that it's not clear whether
constraints are violated when the queries produce results or when
they do <em>not</em> produce results.
<td>Define the function.
<td>
<tr>
<td>NO
<td>4.1
<td>Last
<td>ed
<td>The text says "The following TMQL expressions are evaluated
before each constraint is evaluated." It is not clear what this
means.
<td>Clarify, preferably as part of the definition of <tt>Validate</tt>.
<td>
<tr>
<td>NO
<td>4.2
<td>1
<td>ed
<td>The text says "to facilitate the authoring of TMCL <em>from</em>
CTM", but surely this should be "in"?
<td>Fix wording.
<td>
<tr>
<td>NO
<td>4.2.1
<td>2
<td>te
<td>The URL given for the templates contains neither a version
number nor a date. Wouldn't it be more prudent to include either one
or the other?
<td>Future-proof the URL.
<td>
<tr>
<td>NO
<td>4.2.1
<td>2
<td>te
<td>The CTM fragment uses <tt>%import</tt>, but CTM has no such
operator.
<td>Use <tt>%include</tt>.
<td>
<tr>
<td>NO
<td>4.3
<td>
<td>te
<td>It is not clear whether the topics defined in 4.3.1 - 4.3.5 are
constraints or not. It is also not clear what happens if, for
example, a topic is an instance of another topic which is not an
instance of tmcl:topictype.
<td>Define semantics.
<td>
<tr>
<td>NO
<td>4.3
<td>
<td>te
<td>Using a hyphen in these identifiers, that is, changing
<tt>xtype</tt> to <tt>x-type</tt> offend esthetic sensibilities much
less.
<td>Insert hyphens.
<td>
<tr>
<td>NO
<td>4.4.1
<td>
<td>ed
<td>This clause is a repeat of 4.3.6.
<td>Delete 4.3.6.
<td>
<tr>
<td>NO
<td>4.4.1
<td>
<td>ed
<td>The text says "it has one required occurrence of type". What is
the actual cardinality? 1-1 or 1-*?
<td>Define cardinality.
<td>
<tr>
<td>NO
<td>4.4.7
<td>
<td>te
<td>The query giving the semantics requires "taxonometrics" to be
turned off, but it is possible to specify this while leaving
taxonometrics on. For abstract classes it is an error if there
exists an instance of the abstract class which is not also an
instance of one of its (non-abstract!) subclasses.
<td>Consider changing the query.
<td>
<tr>
<td>NO
<td>4.4.8
<td>
<td>te
<td>The <tt>exclusive-instance</tt> topic is perhaps better called
<tt>exclusive-constraint</tt>, since it really is a constraint? Note
that OWL calls this <tt>disjointWith</tt>.
<td>Rename to <tt>disjoint-constraint</tt>
<td>
<tr>
<td>NO
<td>4.4.8
<td>
<td>te
<td>The normal case is that topic types are exclusive, and for them
not to be exclusive is a rare exception to that rule. In TMCL the
rare case has been made the default, and must be explicitly
overridden. This is awkward and error-prone. Should the default be
changed, and <tt>exclusive-instance</tt> replaced by its opposite?
<td>Discuss.
<td>
<tr>
<td>NO
<td>4.4.8
<td>
<td>ed
<td>How many topic types can appear in a constraint of this type?
Must it always be two, or can it be any number?
<td>Specify cardinality.
<td>
<tr>
<td>NO
<td>4.4.15
<td>
<td>te
<td>Datatypes are specified with an occurrence, which seems very
odd. Surely this should be an association?
<td>Replace occurrence type with an association type.
<td>
<tr>
<td>NO
<td>4.4.18
<td>
<td>te
<td>The <tt>plays-role</tt> template is defined with the association
type as the first parameter, but in the example it is used with the
topic type as the first parameter. The latter is clearly the more
convenient way to use the template.
<td>Change template definition.
<td>
<tr>
<td>NO
<td>4.4.20
<td>
<td>te
<td>Should unique occurrences really be unique only within a
particular topic type?
<td>Discuss.
<td>
<tr>
<td>NO
<td>4.4.20
<td>
<td>te
<td>Why can only occurrence types be unique? What about name types
and association types?
<td>Discuss.
<td>
<tr>
<td>NO
<td>6
<td>
<td>te
<td>This clause is much too vague to actually define how an
extension would work.
<td>Specify how extensions work.
<td>
<tr>
<td>NO
<td>7
<td>
<td>te
<td>This clause ignores the questions of whether schemas are
well-formed, whether implementations must detect this, and what to
do if they are not well-formed.
<td>Take well-formedness into account.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>Symmetric association types are not explicitly supported in
TMCL. It is possible to write schemas with symmetric association
types, but detecting that these association types <em>are</em>
symmetric is awkward. Is a more explicit marker for such association
types needed?
<td>Discuss.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>This specification provides no mechanisms for attaching
information for human readers to the schema. Names are already
provided for by the default name type. However, comments and
descriptions, references to documentation, etc etc are not
provided. Some thought should be given to how this is best taken
care of.
<td>Discuss.
<td>
<tr>
<td>NO
<td>
<td>
<td>te
<td>This specification provides no mechanisms for schema evolution.
OWL, by contrast, can refer to earlier and succeeding versions of a
schema, mark ontology elements as deprecated, and so on. Some
thought should be given to whether these are desirable features for
TMCL.
<td>Discuss.
<td>
</table>