You still didn't answer my question... why is that so bad in this context/paradigm

Are you seriously asking what's wrong with a template system that cannot output "<d>" when you want it to? It's the very definition of failing to meet its requirements.

If <foo> is not a plugin then the parser will have nothing to do with it, hence you can structure it however you please and there will be no effect.

Are you saying one can use "<foo/>" for non-plugins? That's not too bad, then. I wonder how you did that without introducing any other bugs, though.

Are you seriously asking what's wrong with a template system that cannot output <d>

No I'm not, because you can output <d> if you want to. You can use any combination of ascii characters you like, and they will passthrough untouched, unless and only unless, those characters represent a valid and recognised tag to be executed.

In this case, <d> is used by the <db_select> plugin, it's not a plugin itself. If you find a <d> which is inside of a <db_select> tag, then it refers to a selected column, outside of that scope it has no meaning at all.(unless you give it one)

That definition is also not set in stone (very little is in aXML), the <db_select> plugin itself blesses <d> with it's meaning, and it would be quite trivial to update that plugin to use a different token to delimit column names. You could also make it so that <db_select> takes an extra attribute argument to tell it what constitutes a delimiter within it's scope.. I.E:

  <db_select delimiter="FFF">
    <query> SELECT * FROM users</query>
    <mask>
      <FFF>username</FFF><br>
      <FFF>email</FFF><br>
    </mask>
  </db_select>
[download]

There is no limit on how you the designer choose to design your system, it's completely soft coded. You could even do something really esoteric like shove a bunch of jpeg data through it with tags embedded in it which output jpeg data I.E:

sajhfihjufoasd7f83k4jnrjkysaolifgdf
dfydzsxifnyesafqvp3ruioasdcidsfgsdr
uvf<XXX>hello there</XXX>sd'fo8sdfd
0df8sdfksjfd9s8j54rowfskf78susdyvns
7nyrv09sf7nusp98mfs9dfjksdlfewssdkf
[download]

The upshot being, you now have a way of dynamically generating JPG images. Why you would want to do that is beyond me, but it should be possible (I have not tested that theorem)

I think perhaps if you understood where I'm coming from with this it might help, when I was 17 and still wet behind the ears, I spent most of my college life hacking away at graphics demo's in C instead of doing my (boring) COBOL assignments.

I think in a certain way as a result, everything is ultimately data, the computer itself works only with binary and makes no distinction between data and code, that distinction only applies to how we humans think about what we are doing, it's an abstraction to help us out, not the computer which doesn't care. In aXML that abstraction is just not relevant since in aXML data is code and code is data. The structuring of the codedata in terms of the recursive nesting heirarchy of valid tags is all that matters and all the parser concerns itself with.

It doesn't matter if your dealing with a load of pixels or a load of ascii, ultimately it's just numbers which either do or don't have structure, and either do or don't represent valid declarations.

So your response is: You can output "<d>", except when it's a recognized tag, and it commonly a recognized tag.

Was there any point to post?

You could also make it so that <db_select> takes an extra attribute argument to tell it what constitutes a delimiter within it's scope..

That doesn't help. First, suggesting I modify aXML's plugin for me to be able to use aXML is ridiculous.

Even if *you* add that feature to the plugin, it's still doesn't help: What if I want to output "<db_select>"?