Oh what, because part of the post process converts that sequence to a "<"? I already mentioned the possibility of post-inclusion to cover that. (As in an include which occurs after the main processing of the document is done).

Let's make the problem harder, and then solve it shall we?

Take an exceptional case where, the requirement is to extract information from the database which contains specials, for instance a database containing plugin code which uses them for whatever reason. (very few plugins do btw)

In the finest tradition of Perl, we want our baby-aXMLers to be able to do this by writing a simple sequence, supported by code written by a master-aXML/perler if needed.

So our baby aXMLer writes this:

    (db_mask)
      <query> 
         SELECT plugin_code FROM 
         plugins WHERE pluginname=foo
      </query>
      <mask><d>plugin_code</d></mask>
    (/db_mask)
[download]

Then realises that the output he is getting is not quite the same as what is stored in the database, because the code in the database contains examples of the specials which get converted to brackets at the end of processing.

So he hits the manuals or logs into a site such as this one or PerlNights.com, and asks what he can do about it.

A kind friendly soul who understands aXML and Perl then offers him a solution; Add a plugin called something like "present_code", which is used like so:

  [present_code]
    (db_mask)
      <query> 
         SELECT plugin_code FROM 
         plugins WHERE pluginname=foo
      </query>
      <mask><d>plugin_code</d></mask>
    (/db_mask)
  [/present_code]
[download]

With the source of present_code looking something like this:

 present_code => sub { 
                     
     my $data = $_[0];

     $data =~ s@&lab;@<post_inc>common/lab</post_inc>@gs;          
     $data =~ s@&rab;@<post_inc>common/rab</post_inc>@gs;
     $data =~ s@&lsb;@<post_inc>common/lsb</post_inc>@gs;
     $data =~ s@&rsb;@<post_inc>common/rsb</post_inc>@gs;
     $data =~ s@&lcb;@<post_inc>common/lcb</post_inc>@gs;
     $data =~ s@&rcb;@<post_inc>common/rcb</post_inc>@gs;
 
     return $data;
    }
[download]

Then instructs him to make 6 files in his common files dir of his site which each contain their corresponding special char I.E: lab.aXML contains "&lab;" and so on.

The baby aXMLer runs the above code with the new plugin generously coded at obvious labourious length by the master, and finds now he's getting the output he wants.

I've also been thinking about how to make extending the system safer, and the thought occurs that it would not be difficult to create an equivalent of warnings for aXML for instance in the extension module:

 use aXML::Warnings;

 my $plugins = {

         foo => sub { "what a foo" },
  
           b => sub { "I pity the foo" },

         inc => sub { "wanna game of foos-ball?" },

           d => sub { "I've run out of foo jokes" }

      };
[download]

which when run will cause the following warnings to spit out :

Warning: plugin "b" conflicts with HTML tag "b" at line 8.
Warning: plugin "inc" conflicts with aXML tag "inc" at line 10.
Warning: plugin "d" conflicts with aXML tag "db_mask" reserved markup 
+at line 12.
[download]

The warnings would need to know all the available HTML tags and the standard set of aXML tags including their reserved markup. It could just have a list of things to look for.

User defined extensions wouldn't be covered, but by the time people need to write their own extensions they can probably figure it out for themselves, and we could always have an archive like CPAN for extensions categorised by function. And a mechanism to install them and update the datafile which the warnings package refers to when inspecting the code.

I already mentioned the possibility of post-inclusion to cover that.

Yes, it's the third or fourth time you mentioned it, and it's the third or fourth time I've told you it's completely useless. If I'm writing a plugin for someone else, I can't rely on there being a file at common/lab.

With the source of present_code looking something like this:

If you have to tell me what it *might* look like, I can't rely on the user of my plugin to have it, so I can't use it. Useless.

You really should read that to which you reply. It would save you a lot of time since you keep writing huge posts that address the issue I keep raising. You keep assuming one plugin has knowledge of what other plugins are available and an initimate knowledge of what they do (even though you keep saying people can and should just change how plugins behave willy-nilly).

Please show how that is any different from Perl itself not knowing what Modules it might be used with, what modules are installed, what they do, what their dependencies are... and letting end Perl programmers write whatever modules they want "willy-nilly".

The warning approach doesn't work. Every single byte combination is allowed in a text file, so are you planning on warning for every single plugin when creating a text file?