Ok,first off, <d> is not an aXML tag, it's merely markup used by the <db_select> tag. If you attempted to introduce a separate plugin called "d", you would get errors if you didn't use the precedence operators correctly. Having said that there are plenty of ways of putting bad data into any given parser/compiler and causing errors so that in and of itself is not a valid objection to aXML.

It is as unreasonable as saying that Perl cannot be any good because you can't call a sub "die" without interfering with the built in function "die". The given set of abstractions which I have built all work together, and can be changed as the programmer wishes, but there is a difference between extending them logically and deliberately causing conflicts between them by giving them names which interfere with each others markup space.

Secondly, yes the parser as it works right now would require that you write a tag as :

  <foo><bar>moo</bar></foo> 

or, the preferred;

  <foo bar="moo"></foo>
[download]

This is a direct consequence of how the parser I have written works rather than any actual necessity of the syntax/language itself.

A compiler written as Corion suggested would allow for the use of those and of the tag schema your talking about, however as I have already mentioned all attempts I have made to write such a thing have failed miserably and I consider the task "too difficult for me", and more recenly I have come to consider the issue a waste of my time considering the technique is no longer needed for the sake of efficiency thanks to running on top of Plack.

The current code of the parser is as follows, it is a little rough around the edges at the moment because it is still under development, however it does work and it is fast.

 package aXML::Parser;

 use Modern::Perl;
 use aXML::Engine;

 my ( $aXML,$env,$qd,$session,$cookie,$conf,$dbh,$debug_trace );

 sub process {

   $aXML = $_[0]; $env = $_[1]; $qd = $_[2]; $session = $_[3]; $cookie
+ = $_[4]; $conf = $_[5]; $dbh = $_[6];

   $aXML =~ s@`@<backtick>@g;

   my $plugins = aXML::Engine::init( $env,$qd,$session,$cookie,$conf,$
+dbh );
   $aXML::Engine::scan_more = 1;

   my $tag_found;

   while ($aXML::Engine::scan_more)
       {
        $aXML::Engine::scan_more = 0;
        $aXML::Engine::redo = 0;

        $tag_found = 0;
        $aXML =~ s@\(([^/\s\)]+)([^\)]*?)\)@ do { if (defined $plugins
+->{ $1 })
                                                    { $tag_found = 1; 
+"(`$1$2)" }
                                                  else { "($1$2)" }
                                                }
                                           @egs;
        if ( $tag_found )
          {
           while($aXML =~ s@\(`([^`\s]+)([^`\)]*?)\)([^`]*?)\(/\1\)@ d
+o {
                                                   my $command_args = 
+aXML::Engine::parse_args( "$1$2" );
                                                   my $data = $3;
                                                   $data =~ s/<null>//
+gs;
                                                   $plugins->{ $comman
+d_args->{'tag_name'} }->( $data,$command_args );
                                                }
                                          @egs ){}
          }


        unless ( $aXML::Engine::redo )
          {
           $tag_found = 0;
           $aXML =~ s@<([^/\s>]+)([^>]*?)>@ do {
                                      if (defined $plugins->{ $1 })
                                       { $tag_found = 1; "<`$1$2>" }
                                      else { "<$1$2>" }
                                     }
                                @egs;
           if ( $tag_found )
             {
              while($aXML =~ s@<`([^`\s]+)([^`\>]*?)>([^`]*?)</\1>@ do
+ {
                                                    my $command_args =
+ aXML::Engine::parse_args( "$1$2" );
                                                    my $data = $3;
                                                    $data =~ s/<null>/
+/gs;
                                                    $plugins->{ $comma
+nd_args->{'tag_name'} }->( $data,$command_args );
                                                 }
                                            @egs ){}
             }
          }

        unless ( $aXML::Engine::redo )
          {
           $tag_found = 0;
           $aXML =~ s@\[([^/\s\]]+)([^\]]*?)\]@ do { if (defined $plug
+ins->{ $1 })
                                                   { $tag_found = 1; "
+[`$1$2]" }
                                                 else { "[$1$2]" }
                                               }
                                          @egs;
           if ( $tag_found )
             {
              while($aXML =~ s@\[`([^`\s\]]+)([^`\]]*?)\]([^`]*?)\[/\1
+\]@ do {
                                                      my $command_args
+ = aXML::Engine::parse_args( "$1$2" );
                                                      my $data = $3;
                                                      $data =~ s/<null
+>//gs;
                                                      $plugins->{ $com
+mand_args->{'tag_name'} }->( $data,$command_args );
                                                 }
                                            @egs ){}
            }
          }
       }

   $aXML =~ s@`@@gs;
   $aXML =~ s@<backtick>@`@gs;
   $aXML =~ s@<null>@@gs;

   return "$aXML $debug_trace" if $debug_trace;

   return $aXML;
  }






1;
[download]

It is as unreasonable as saying that Perl cannot be any good because you can't call a sub "die"

Actually, Perl does allow you to create a sub named die, and it provides a method of calling the real die if you override die.

A better example would be string literals. aXML is a like a Perl that's doesn't allow strings that contains «"» to be constructed. It is most definitely reasonable to be able to construct a string that contains «"». That's why Perl provides an escape character and the ability to change delimiters.

aXML does not have the equivalent of an escape character; it cannot distinguish code from data. That's really really really really really really bad.

Secondly, yes the parser as it works right now would require that you write a tag as <foo><bar>moo</bar></foo> or ...

uh, no, «<foo bar="moo"></foo>» is not equivalent to «<foo><bar>moo</bar></foo>». If aXML transforms one in tho the other, it's yet another major problem with aXML.

it cannot distinguish code from data. That's really really really really really really bad.

It sounds, to my untrained ear, like you just condemned the entire Lisp language family and several others.

I just copy/pasted «"» into an aXML document and ran it to see what would happen, and it there was no effect. The document rendered correctly and the browser displayed the characters, so I can't see the problem?

aXML doesn't need an escape character, it doesn't try to distinguish code from data, in aXML code and data are one and the same.

You iterate repeatedly that that is bad, and yet you do not qualify that statement, are you repeating some obsolete mantra you learned at university regarding the classical way of doing things or do you have a real specific reason for that argument in this context/paradigm?

With regard to your other point, in aXML the only difference between <foo bar="moo"></foo> and <foo><bar>moo</bar></foo> Is that bar as an attribute will be available to the plugin in the hash of attributes found in $_[0], whilst as an internal tag it will be found in the tag data string $_[1] and have to be extracted manually by the plugin itself if it uses it. That is why the former is the preferred format for plugins which require certain input values to determine their output.