It's not the worst solution, but it's inherently fragile.

It requires that I know every element name that can be found in an XML document. Some formats are extensible (e.g. XHTML), so there is no such list for them. And even if we assume that list can be found, most people won't bother trying to create it.

It requires that I cross check that list against the list of keywords in a hash. How is that possible to do reliably if the list if as dynamic as you say.

This will lead to errors that can be very subtle. And given how templates are typically used, the errors will not be seen by the dev and they will be seen by end users.

The thing is, XML has already solved that problem. The mechanism is called "namespaces".

<root xmlns:a="http://axml.com/1.0/">

<a:inc title="User Info">header</a:inc>

<table border=0 width="100%">
  <tr>
    <th>User ID</th> 
    <th>Name</th>  
    <th>Email</th>
  </tr>
<a:db_select>
  <a:query> SELECT * FROM user ORDER BY id </a:query>
  <a:mask>
    <tr>
      <td><a:d>id</a:d></td>
      <td>[hlink action="user_profile" user_id="<a:d>id</a:d>"]<a:d>na
+me</a:d>[/hlink]</td>
      <td><a:d>email</a:d></td>
    </tr>
  </a:mask>
</a:db_select>  
</table>

<a:inc>footer</a:inc>

</root>
[download]

PS — I personally prefer <inc name="header"/> over <inc>header</inc>.

...It requires that I know every element name that can be found in an XML document...

Ok then, we add a new sub called something like <no_parse> which takes a path to the XML to be included in the output. The file is loaded and stored in memory and inserted after the parser has exited. That way it doesn't matter if the file to be included contains tags which match the plugins because it wont be seen by the parser. The original version has something similar to that called <ignore>, but I haven't got round to creating that functionality in the new one yet.

Oh and regarding shortend tags like <inc name="header"/> I like that, however supporting those sort of tags as well as the standard ones will require extra compute time under the current methodology. It's perfectly possible to do, but I'm not sure the gain would be worth the overhead.

That's not to say that the current methodology is the be all and end all, Corion once suggested writing a compiler for aXML which would solve that problem and further improve overall performance, however such a solution is currently over my head and given how blazing fast the current version is I just can't feel the desire to try and implement it (again).

Ok then, we add a new sub called something like <no_parse>

That wouldn't work.

Oh and regarding shortend tags like <inc name="header"/>

It wasn't shortened. It's actually three characters longer. It just seems clearer to me for inc

however supporting those sort of tags as well as the standard ones

I wasn't suggesting that you handle both <inc>header</inc> and <inc name="header"/>, just one of them. Supporting both would be confusing.

So what does your system do right now when it sees a tag like <tag />? Does it get ignored?