[sc34wg3] Feedback on the CTM draft

[Lars Marius Garshol]

The draft is somewhat tricky to evaluate, since it's not really a  
specification, but more like a tutorial. It's also a rather  
superficial tutorial, unfortunately. I would particularly have liked  
to see the BNF included together with the examples, and the text  
centered around the BNF, with examples as support. (The XML  
Recommendation sets a good example in this regard, BTW.)

--- 1

It's not true that CTM is defined through a mapping to TMDM. This is  
what the spec should do when we have one, but this isn't true yet.

--- 3

The EBNF in annex A is not the ISO EBNF, which is very different. The  
EBNF used in annex is that from the XML Recommendation. I would keep  
the EBNF as it is and just reference the XML Rec instead. This is  
what TMQL does.

Why is there are normative reference to XTM? I didn't find any such  
references in the text.

--- 4

I would cut this section. It serves no purpose.

--- 5.1.1

TMQL uses only the # comment syntax. Do we really need the /* ... */  
comments? Personally, I'd prefer to see only #.

--- 5.1.2

Why do HTTP URIs get special treatment? And why use '<' and '>' as  
delimiters? IMHO those should be avoided, for obvious reasons.

--- 5.1.3

Why use both " and """ for strings? Isn't it enough to just allow  
line breaks inside single-quote strings?

--- 5.2.5

If the encoding declaration is to have any value it must be required  
to appear first in the document, before any whitespace or other  
characters. This is so that it is possible to detect the basic *type*  
of encoding in cases where it is not ASCII-compatible (UTF-16,  
UTF-32, EBCDIC, ...).

--- 5.2.6

Are the <>s really needed here?

--- 5.2.7.1

Including scope in the name and occurrence type declaration is not a  
good idea. This means including the scope for every instance of those  
types, which strongly implies that the scope is in fact a statement  
about the name/occurrence type, and not about the individual  
instances. This seems like poor modelling.

--- 5.2.7.2

Why allow the datatype here? Is it for when the datatype is not one  
of the predefined ones, to avoid repetition?

--- 5.3.8

NOTE 5 should follow from the EBNF.

Why can assertion blocks be terminated either with a blank line *or*  
a period? It should be one or the other. Given that line breaks have  
no significance anywhere else in CTM it seems strange for them to  
assume significance here. (Of course, one could get rid of some of  
the delimiters inside assertion blocks using line breaks instead,  
which might actually be a better option.)

--- 5.3.9.5

Please find some other solution than the %ROLE syntax. Another  
keyword (NULL) might work better, but %ROLE is really ugly.

ISA is dubious, but used in TMQL. It's true that it is ambiguous  
(there is no reason why ISA couldn't be used for subclassing as  
well). I don't think a special predefined syntax for superclass/ 
subclass is necessary.

--- 5.3.11

The syntax for reifying the TM is unattractive. The ctm:self option  
is not too pretty, either. Personally, I think I prefer a directive  
for this.

--- 6

This section is OK for now, but does not belong in the final standard.

--- Annex A

I spent some time with this, but it's hard to read without any text,  
and it doesn't really seem 100% coherent. I've skipped diving deep  
before we have a more proper specification.

There should be a general statement about the handling of whitespace  
here, since whitespace is generally omitted in the grammar.

Comments should not be included in the grammar, since they are  
removed in the lexing stage.

Why allow prefix-directives and templates to mixed in with assertion  
blocks?

The definition of version-directive looks wrong. It says that
   %version  ctm 1.0
is syntactically invalid, but that seems very strange.

The EOL{2} syntax is not used in the XML Rec. There's no need,  
anyway, as EOL EOL would do just as well.

The constraint on name-type does not belong in the BNF. Not sure the  
constraint makes any sense, anyway.

The NOTE about IRIs is not actually a NOTE (it's normative), and it  
belongs in the spec proper, anyway, together with the BNF.

Why does WS not include \r?

--
Lars Marius Garshol, Ontopian               http://www.ontopia.net
+47 98 21 55 50                             http://www.garshol.priv.no