I'm going to add that sub escape in the parser right now

The point of escape is to prevent aXML from processing that which is passed to the function. It is used by plugins, not aXML. aXML performs the *reverse* operation after the template has been fully processed.

my %escapes = (
   '&lab;' => '<',
   '&rab;' => '>',
   '&lcb;' => '(',
   '&rcb;' => ')',
   '&lsb;' => '[',
   '&rsb;' => ']',
);

sub final_processing {
   my ($content) = @_;
   $content =~ s{
      (?: (&[lr][acs]b;)
      |   <special...>(...)</special>
      |   <post_include...>(...)</post_include>
      )
   }{
      if (defined($1)) {
         $escapes{$1}
      }
      elsif (defined($2)) {
         '&'.$2.';'
      }
      else {
         ...
      }
   }xeg;

   return $content;
}
[download]

Huh?

I have this gut feeling, about which I am by no-means certain, that if you were to build a compiler based on how your currently thinking aXML should work, it would be very fast but would not render certain documents correctly. Specifically documents which contain higher level compound aXML statements.

The only analogy I can think of right now is if I handed you a Lego Technic kit that you can build a transformer out of, composed of lots of lovely little pieces designed to fit together and to transform smoothly from their initial state to their final state, and you took it to pieces added a few constraints to several of the blocks, and then put it back together again, it would no longer transform correctly.

Optimus Prime would be a cripple.

Look I don't know... as I said before I've only begun to scratch the surface of how aXML units can inter-operate and transform themselves and each other from the initial state to the rendered state.

All I know is that by using the quasi-xml style markup, the transformation is well structured and guided by the structure to perform the same transition smoothly time and time again.

When I was working with the thing at the start, speed and efficiency were not my primary concerns. The flexibility and expressivity of the language were. I figured that I could solve the efficiency issues later. (which I have now to sufficient degree for my usages)

Now, thing is right, just because I came up with the schema doesn't mean I know everything about it or that the way I use it is necessarily the ideal way of using it. I recognise that fact and welcome anyone wanting to come up with any sort of variant on it.

All I can say is that I've found a pattern that works for me, and is the best way to use it that I have been able to conceive of so far.

Basically in my PSGI file, all documents start out with the same identical seed :

my $action = sub {
      return [200, [ 'Content-Type' => 'text/aXML' ],
                   [ '(use)(qd)action(/qd)(/use)'  ] ]; };
[download]

This is the same as saying :

my $action = sub {
     
return [200, [ 'Content-Type' => 'text/aXML' ],

       [ 
         process(

          "$doc_root/actions/$qd->{'action'}/body.aXML" 

                ) 
       ] 
    ]; 
};
[download]

The Plack::Middleware::aXML component takes that seed and from that point the parser iterates over the document as many times as needed transforming it one step at a time into the final result.

Typically, at least in my code, the body.aXML that is loaded contains a call to include a template, either the public page template or the private page template (for the control panel pages for instance), which then has further processing directives in it. Some of the body.aXML files also contain calls to do some processing prior to loading the template, so that the template will render correctly after something has changed, for instance the user preference for CSS colour scheme.

If plugins are not able to return valid markup for the parser to pickup on on it's next iteration, the "use" statement would be useless, and processing would halt at that point because the inserted template would not contain any directives the parser can recognise.

Autobots! Transform! .... *CRUNCH*... er...

The only analogy I can think of right now is if I handed you a Lego Technic kit that you can build a transformer out of, composed of lots of lovely little pieces designed to fit together and to transform smoothly from their initial state to their final state

The problem is that the little pieces don't fit together in what you handed me. There are some connectors missing. I'm slowly getting you to realise these connectors are missing.

would not render certain documents correctly.

Only if you misapply it.

Your current flow is:

plugin produces aXML code,
   parser takes that aXML code and produces HTML code,
      browser takes that HTML code and produces text.
[download]

Except your plugins don't always produce aXML code. For example, look at d. IIRC, you said it currently produces HTML. escape addresses that bug. It will convert the HTML into aXML.

text_to_aXML: The "escape" function I posted, renamed for clarity.
text_to_html: Converts & to &amp, < to &lt, etc.

# Current
sub d {
   my $text = ...;
   return text_to_html($text);
}

# Should be
sub d {
   my $text = ...;
   return text_to_aXML(text_to_html($text));
}
[download]

You seem to be considering what would happen if every plugin used it, and indeed that would make no sense.