Re: XSP Backwards

[Paul Russell <pa...@luminas.co.uk>]

On Wed, May 24, 2000 at 09:32:53AM -0500, Ricardo Rocha wrote:
> For this, though, we need to resurrect DOM support in Cocoon2.

Err... do we? We've already got classes for creating DOM trees
from SAX events and v/v... do we *really* need anything else?

> Last but not least, the internal XSP code generation
> mechanism is still DOM-based (and it's likely it remain so as
> this representation appears to be more appropriate for this
> purpose).

Nothing wrong with that. Right tool for the job, 'n' all
that. Afterall, the reason the core is SAX is to allow a
document to progress through the framework without having
to do a 'full halt' at each stage. Until we've generated
*all* the java code from the XSP, we have to stop the flow
of XML anyway, so using DOM here has no adverse affect.

> 1) Restoring some of DOM's former first-class citizen status
>    (at least in terms of parser support).

Did it ever lose it?! DOM *still* rocks for some stuff.

> 2) Wraping the previous, DOM-based version of XSP as a "new"
>    markup language

Seems like a very sensible approach. +1.


-- 
Paul Russell                               <pa...@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.