[sc34wg3] TMCL comments
Patrick Durusau
patrick at durusau.net
Tue Oct 7 11:05:50 EDT 2008
Lars,
Thanks for these comments as well. Obviously more of these are going to
require discussion than most of the CTM comments but for those that
won't, a summary of changes proposed by the editors would be useful here
as well.
Hope you are having a great day!
Patrick
Lars Marius Garshol wrote:
>
> Attached are my TMCL comments. These are higher-level than the CTM
> comments, and most of this needs to be discussed in the committee. I'm
> hoping we can do that in Leipzig.
>
> --Lars M.
> http://www.garshol.priv.no/blog/
> http://www.garshol.priv.no/tmphoto/
>
>
> ------------------------------------------------------------------------
>
> MB Clause no. Paragraph Type of comment Comment Proposed change
> Sec obs
> NO ed "Therefore" is consistently spelled "therefor" (which
> has a different meaning) throughout. Correct the spelling.
> NO ed 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. Introduce a subclause "4.1 General"
> before the current 4.1.
> NO te The CTM throughout is lacking the period (.) to close
> the topic blocks. Without this the CTM is incorrect. Correct the CTM.
> NO te The CTM throughout is lacking the semicolon (;) to
> terminate statements. Correct the CTM.
> NO te 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.
>
> 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.
>
> Needs discussion.
> NO te 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. Add
> annex with meta-schema, possibly placeholder.
> NO te 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. Change identifiers to consistently use hyphen-based naming.
> NO te 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.
>
> Possible solutions:
>
> * Find some way to shoehorn MAX_INT into CTM (and XTM 1.0/2.0!).
> * Support optional arguments in CTM templates.
> * 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.
> * Define extra templates (with different names) which omit the max
> cardinality argument (implicitly setting it to infinity).
>
> Needs discussion.
> NO Intro ed This introduction is too short and doesn't really do
> much to introduce TMCL. Write a longer introduction.
> NO Scope ed TMCL is referred to as a "data model", but strictly
> speaking it is a Topic Maps vocabulary. Correct the language.
> NO 3 ed The function notation used in 4.1 is not defined. Add a
> definition of this notation.
> NO 4 2 ed This text repeats statements already made. Remove
> paragraph.
> NO 4 3 te 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.
>
> 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.
>
> Change so that the queries are given in the spec only.
> NO 4 3 ed 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". Fix formatting and typos.
> NO 4.1 2 ed The variable $THIS is defined here, but the queries as
> given actually use $this. Lowercase the variable name.
> NO 4.1 3 ed 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? Correct the wording.
> NO 4.1 5 ed The Validate 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 /not/
> produce results. Define the function.
> NO 4.1 Last ed The text says "The following TMQL expressions are
> evaluated before each constraint is evaluated." It is not clear what
> this means. Clarify, preferably as part of the definition of
> Validate.
> NO 4.2 1 ed The text says "to facilitate the authoring of TMCL
> /from/ CTM", but surely this should be "in"? Fix wording.
> NO 4.2.1 2 te 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? Future-proof the URL.
> NO 4.2.1 2 te The CTM fragment uses %import, but CTM has no such
> operator. Use %include.
> NO 4.3 te 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. Define semantics.
> NO 4.3 te Using a hyphen in these identifiers, that is, changing
> xtype to x-type offend esthetic sensibilities much less. Insert
> hyphens.
> NO 4.4.1 ed This clause is a repeat of 4.3.6. Delete 4.3.6.
> NO 4.4.1 ed The text says "it has one required occurrence of
> type". What is the actual cardinality? 1-1 or 1-*? Define
> cardinality.
> NO 4.4.7 te 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. Consider changing
> the query.
> NO 4.4.8 te The exclusive-instance topic is perhaps better
> called exclusive-constraint, since it really is a constraint? Note
> that OWL calls this disjointWith. Rename to disjoint-constraint
> NO 4.4.8 te 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 exclusive-instance replaced by its opposite? Discuss.
> NO 4.4.8 ed How many topic types can appear in a constraint of
> this type? Must it always be two, or can it be any number? Specify
> cardinality.
> NO 4.4.15 te Datatypes are specified with an occurrence, which
> seems very odd. Surely this should be an association? Replace
> occurrence type with an association type.
> NO 4.4.18 te The plays-role 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. Change template definition.
> NO 4.4.20 te Should unique occurrences really be unique only
> within a particular topic type? Discuss.
> NO 4.4.20 te Why can only occurrence types be unique? What about
> name types and association types? Discuss.
> NO 6 te This clause is much too vague to actually define how an
> extension would work. Specify how extensions work.
> NO 7 te 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. Take well-formedness into account.
> NO te 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 /are/ symmetric is
> awkward. Is a more explicit marker for such association types
> needed? Discuss.
> NO te 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.
> Discuss.
> NO te 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. Discuss.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3 at isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>
--
Patrick Durusau
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
More information about the sc34wg3
mailing list