request for comment: adding xslt processing to mapserver

[Kralidis,Tom [Burlington]]

Thanks for all the comments and viewpoints.

I think some good points have been made w.r.t. for/against this change
in MapServer.

For me, I think having XSLT support allows MapServer to be more flexible
and extensible, especially from a user point of view (when I say user in
this context, I mean someone versed in MapServer-ness and XML).  There
are a lot of these folks).  Many of whom have to layer brokers atop
their processes (like, say, cocoon).  I realize that this is
(technically) not a showstopper, however, in some instances, there is
overhead involved in inistitutionally/organizationally plopping more
software/languages/tools.  Especially for a production environment.

This was originally envisioned as an easy, OPTIONAL, way to morph
MapServer's very basic XML output into something which could be more
self-describing for information communities.  At the same time, I hear
the issues w.r.t. why we shouldn't go this way.  One big one for me is
the inverting of XSLT processing, i.e. when a client makes a query (say,
a Filter encoding statement) to a server with a transformed content
model.  This presents a hurdle to additionally define an XSLT which maps
incoming elements to the actual element names which are derived from the
underlying data binding.

Perhaps the biggest issue this has raised is the need for a discussion
of the future of MapServer XML support (i.e. msIO_printf vs. libxml2).
Most of MapServer XML is msIO_printf.  The relatively recent OGC:SOS and
OGC:OWS support is libxml2.  Before any decision on XSLT is made, I
think we need to hash this out.  Comments?

Specific email on this subject to follow in the next day or so.

..Tom


> -----Original Message-----
> From: UMN MapServer Developers List 
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Frank Warmerdam
> Sent: 28 March, 2007 5:36 PM
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-DEV] request for comment: adding 
> xslt processing to mapserver
> 
> Paul Spencer wrote:
> > Yes, the memory requirements seem to be the biggest 
> argument against.  
> > The problem when considering implementing xslt is that there is no 
> > real solution to streaming xslt transformations so the 
> whole document 
> > has to be read into memory somewhere.  Not doing it in 
> mapserver just 
> > defers the problem to another process on the same machine or on 
> > another machine.  So why not just take the hit in mapserver?
> 
> Paul,
> 
> I agree that doing it in memory seems unavoidable when doing 
> xslt transformations.  But I don't want to bring this 
> requirement on all WFS use - for instance by changing the 
> code to use libxml2 for all WFS responses.
> 
> I like the angle of capturing XML output via the msIO 
> redirection stuff, if and only if xslt transformation will be 
> applied.  Though the downside here is that an extra 
> parsing/serializing pass is required.
> 
> Best regards,
> -- 
> ---------------------------------------+----------------------
> ----------
> ---------------------------------------+------
> I set the clouds in motion - turn up   | Frank Warmerdam, 
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo, 
> http://osgeo.org
>