Matt Sergeant wrote:
>
> To picture this better I imagine it as a forward moving pipeline, from
> initial "resource" (the XML file, or whatever the URL maps to), to
> delivering the file:
>
> Res ---> Process ---> Process ---> Process ---> Delivery
>
I think this is an interesting way of looking at things, took
me a while to get my head around why ASP didn't fit into
this model, because ASP usually isn't raw data right?
I think this limitation in the ASP model was striking which
was a motivation between XMLSubs taglibs in Apache::ASP.
<my:tag>
Some content
<my:deeptag>
More Content
</my:deeptag>
</my:tag>
What happens here with XMLSubsMatch my: is each tag
level acts as your Res(ource), and the final output
HTML, gets passed to the higher up enclosing sub for
processing. This can be right along side any normal
ASP scripting, and this mesh model gives you what you
need when you need it.
Alternatively with XSLT & Apache::ASP, the ASP script
becomes the XML resource, static or scripted, translated
by a separate possibly scripted XSLT stylesheet.
But what I find curious is that you denoted no perlspace
for AxKit, and when looking at XPathScript, it seemed like
there would be, so what I perhaps am missing the subtleties
as to why AxKit necessarily doesn't have a perl space, I thought
the perl scripted XML processing was quite a nice touch actually.
Maybe your "processor" doesn't count if it is perl feeding
directly off an XML datasource?
-- Joshua
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
