[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