[sc34wg3] CTM draft dtd. 2007-09-09 - Templates

Gabriel Hopmans g.hopmans at mssm.nl
Mon Oct 8 10:57:13 EDT 2007

Hi all,

On 9/27/07, Lars Marius Garshol <larsga at garshol.priv.no> wrote:
> * Lars Heuer
> >
> > In the previous example it would be impossible to create an occurrence
> > of type 'homepage' *after* we have a declared a template called
> > 'homepage'.
> >
> > IMO this is bad. The user gets two different behaviours for the same
> > syntax. And if the user makes a typo within the template name, the
> > parser would not claim that error, but create an occurrence silently
> > (unless the argument cannot be a valid occurrence value).
> >
> > With the CTM syntax *before* Montreal, the parser would have
> > detected typos and the user wouldn't have got two different things
> > within the same syntax.
> >
> > I propose to make template invocation syntax and occurrence syntax
> > distinct (again). Either we should go back to the syntax before
> > Montréal or someone should come up with a better one.
> What we have here is a group of requirements which are mutually
> incompatible, as follows:
> #1: Syntax should have a uniform look
>      (ie: occurrences & templates should look the same)
> #2: The meaning of a single expression like "foo: bar" should not
>      change throughout the file
>      (ie: template definitions should not change the meaning of this
>      expression)
> #3: It should be possible to define templates anywhere in a file
> It's possible to have any two of these, but not all three. So, it
> boils down to a question of which requirement is the least important
> to people. I guess we could do a quick poll or something.
> Steve suggested an alternative solution: require template identifiers
> and topic identifiers to be distinct. In this case you'd have to
> check every declared template to see if there is a topic with that
> identifier and if so report and error, and conversely also check for
> conflicts with every new topic. This does add complexity to
> implementations.
> There is the potential for trouble with %include, but given that %
> include will only work where identifiers are carefully managed across
> files anyway, I think we can ignore that problem.
> In addition, we have another requirement, introduced by Lars Heuer:
> #4: Mistyped template names should cause an error
> This one conflicts directly with #1, so anyone who wants this
> basically ditches #1, so that they can have #2 and #3.
> As far as I am able to tell, this leaves us with the following options:
>   - #1 and #3: basically the post-Montreal syntax
>   - #1, #2, #3 and errors on shared identifiers: current draft + new
> rule
>   - #2, #3, #4: back to distinguishing templates & occurrences
>   - #1, #2: means templates must be defined at top of file
>     not clear if this is compatible with new %include semantics
> Personally, I don't like the "errors on shared identifiers" solution
> very much, and I don't think #1 is important. (I let it pass in
> Montreal, not realizing that this was a side-effect.) So basically, I
> prefer the #2-#4 solution.
> As far as I can tell, Steve favours #1-#3 plus errors.
> Lars, I think, favours #2-#4, like me.
> Unless I've missed it, nobody else has given any opinion so far.

There is maybe another side-effect for TMQL if we go for #1. The CTM
declaration within the query language will also contain colons for binary
association templations.

I favour #2-#4 as well.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.petesbox.net/pipermail/sc34wg3/attachments/20071008/375f5d8b/attachment.htm

More information about the sc34wg3 mailing list