Talli, also check this thread on XML like syntax for a templating system. IMHO, actually making ADPs and ATS conform to XML would be unhelpful. XSL achieves it by interpreting its XML tags and rewriting the surrounding XML/text. But it isn't very readable, and this type of process is probably impossible for ADP and ATS processing.
In the above thread I discuss the possibility of a separate templating system with improved properties in certain areas. One area is validation of the template.
Without going to the extreme of XSL, I doubt you can construct an valid XML document that is also a template. The main problem is attribute values, whose value validation probably wouldn't match up in many cases with the variable format. But a template doesn't have to be valid XML to be a valid template, obviously. What would be nice is if the templating system could validate the template while transforming it into code. This is the approach I have taken.
The ATS compiler could be rewritten to do this as well. Essentially you would throw out the adp tag processor and replace it with a top down scanner/parser. The recursive nature of the ATS compiler makes it difficult to understand and extend. Since my new toy is top down, it is very easy to extend. For instance, this weekend I added the following 'tag':
[resource type name args]
# which is converted by the scanner/parser to:
if {[::resource::exists $type $name]} {
::resource::eval $type $name $args
}
# ::resource::eval in turn, just runs:
::resource::$type $name $args
So to answer your question, Talli: it may not be impossible, but I don't see any advantages given what the result would look like. And it doesn't appear that the toolkit has room for another templating system, regardless of the properties.
