You looking at it with a bias that you seem unaware of, whilst I agree the above example is a very nice neat bit of masters Perl, it is beyond the understanding level of the target user base.

My plan is and always was to make good structure easy and implicit, such that cheap spaghetti brained code monkeys who find things like PHP to be a challenge to the upper level of their intellectual capacity, can produce well structured and reusable apps quicker and easier than they can using things like PHP.

If they then graduate onto the level of writing plugins good for them, if they then continue to grow as a programmer and learn enough to write masters Perl, good for them and good for Perl. Most of them will never attain that level, the vast majority will do exactly what they are doing now, cutting and pasting code with very little understanding of what they are actually doing or why the spaghetti messes they make are bad.

You can golf your code down as much as you like and marvel at how few keystrokes your using, but as soon as you use 'magic' symbolism in there, you've just lost most of the audience.

There is a reason why Master Perl programmers earn upwards of £60,000 a year; they are in short supply because most programmers are not smart enough to reach that level.

There is a very good reason why Larry is so keen on allowing for Baby perl to exist without being punished, it's because he knows that not only is today's baby perler potentially tommorrows master, but also that the distribution curve of IQ points in the population means that baby perlers will always outnumber masters by many to one, and failing to support them in favour of top end people capable of writing things like your example, is a surefire way to end up with a language only intellectuals like us can appreciate.

There will always be a 1 : 1 mapping of aXML code to perl code, because aXML is written in Perl. And the perl code will always be both more efficient and flexible, provided that the programmer has sufficient understanding of the language to use and debug it. For the same reasons that their will always be a 1 : 1 mapping of Perl code to C code, and a programmer capable of writing the Code in C will also gain in terms of efficiency and flexibility. Its as true to say that only aXML can parse aXML as it is to say that only Perl can parse Perl, and for the same reasons!

Another thing is that the example I gave was just to illustrate how the structure works, the system is not intended to be a replacement for the syntax of perl, but to be complimentary too it.

It would be interesting to see just how many lines of Perl you need to trigger the same functionality as this example:

<batchvalidate>
  <test rule="username_not_taken" 
     username="<qd>username</qd>"
     >
      [mem ref="username_error"]1[/mem]
  </test>
  <success>
    [use]adduser[/use]
  <success>
  <failure>
    [use]signup[/use]
  </failure>
</batchvalidate>
[download]

Where there can be multiple tests, and the example connects to the database, checks if the username exists in the users table, and then decides what to do based on the results.

I would suggest the equivalent Perl code, if given in it's entirety like your example would be something like this;

   use Plack::Request;
   use DBI;   
   use Conf;
   use Modern::Perl;

   my $env = shift;
   my $qd  = $req->parameters->mixed;

   my $dbh = DBI->connect(
  
          $Conf::conf->{'dsn'},
          $Conf::conf->{'dsn_username'},
          $Conf::conf->{'dsn_password'}
      
      ) || die "Could not connect to 
                  database: $DBI::errstr";

  my $sth = $dbh->prepare(qq@ 

        SELECT count(1) FROM users 
        WHERE username="$qd->{'username'}"

      @);

  $sth->execute;

  ....
  ....
[download]

Blah I can't even be bothered finishing this example, if you don't get the point I'm making then maybe you never will.