Hello everyone, There has been some work going on within the team to get ideas (and code) into better shape with template. The result of the work is the xtemplate package. There are still open questions that we are working on, and also some where more input would be very helpful. I'll try to outline what we have done and what remains to be decided. ======================================================================= The ideas are laid out in the dtx: Will has done a good job of setting them out there, and I'm not going to repeat it! For people familiar with template, you'll see that we've renamed \DeclareTemplateType to \DeclareObjectType, as the old name was downright misleading. The keyval system has been completely revised in xtemplate. This is because it became clear we wanted some "self-documentation" in the keys. The idea now is to divide things into two: - \DeclareTemplateInterface. This sets up the names of keys in a template and the type of argument they expect (skips, functions, etc.). It also includes default values. - \DeclareTemplateCode. Sets up the implementation of the keys. The reason for this is that the interface should be understandable without needing to know about the code. So the aim is that you can look at the arguments to \DeclareTemplateInterface and know what you might want to change, without looking at \DeclareTemplateCode at all. Most of the ideas for instances and collections have not changed (at the moment). ======================================================================= There are a number of things that still need sorting out. In no particular order, I'll list the ones I remember. The key types are in the main pretty easy to follow. One that I'm not sure about is "tokenlist". In the context of designing templates, "text" would seem to make sense here, as this is really what is intended. If the interface is supposed to help designers, the TeX token concept is not necessarily helping much. \MultiSelection has not been moved to xtemplate from template. That is because it'd not clear quite what to do yet. The general question is how to make one key depend in some way on another. Frank suggested some "stories": - set the vertical space between items of a list depending on the list context (i.e., the list depth) -> that is an index like spec - set the vertical space before a heading to X except when the heading is immediately preceded by another heading (in which case use Y) but use Z if the heading falls on the top of a new page -> that is not an index like spec - set some length to the max of X and the current value of variable V taken from the context of the instance So something that uses an index is one possibility, but only covers some scenarios. The question is therefore what situations need support at the level of xtemplate (as opposed to being handled in the code part of a template). The collections idea is currently probably not quite right. A while ago, Frank said: 'What exactly should collection instances be used for? I'm starting to question how much use they actually provide as they offer exactly one level of variance and often you would have several layers, e.g., would "frontmatter", "mainmatter", "backmatter" be good candidates for collections? So that, for example, pagestyles behave differently in those places? But then this should also influence the way headings are set (would be possible) and in the way page numbers are displayed (more difficult perhaps). And what happens if somebody else come up with a different type of collection, e.g., making "minipage" a collection to change behaviour or stuff inside. Then who wins? And why?' and that still applies. As collections are about design, I can't myself see how more than one can be in force at any time, but can see the problem of keeping things in sync. The code currently sticks close to the original template concept, but this probably needs to change. The argument order of some of the functions probably needs rethinking. This will probably have to be decided after other stuff is sorted out! ======================================================================= Thoughts on any part of (x)template very welcome. It's clear that some problems will have to be revisited as more use is made of templates: we can't hope to know everything now! -- Joseph Wright