request for comment: adding xslt processing to mapserver

[Paul Spencer]

Thanks for the feedback, Frank ... a couple of comments below ...

On 28-Mar-07, at 4:47 PM, Frank Warmerdam wrote:

> Paul Spencer wrote:
>> Correct, it could be accomplished using WxS.  One of the  
>> objectives of this work would be to reduce the IT infrastructure  
>> requirements for deploying new OGC services.   Using WxS is  
>> equivalent to using an external service in this case, and would  
>> require the following additional steps beyond using a mapserv cgi:
>> * building and installing mapserv with a mapscript extension
>> * configuring web server for the particular flavour of mapscript  
>> you want to use
>> * ensuring the scripting language has packages for xml and xslt
>> * writing/maintaining code in the mapscript language to implement  
>> the parsing and transformation
>> * maintaining the scripting language installation over time as  
>> security patches come out (etc)
>
> Paul,
>
> I don't honestly find this a compelling argument.  I'd think the  
> project
> could be cast as producing some php functions to do the xslt via  
> mapscript.
> If a person is using pre-built binaries like MS4W or FGS that includes
> php then presumably all the other stuff would be taken care of.

Fair enough, this kind of situation does not apply to everyone (or  
even very many people).  Certainly my inclination would be to do it  
in PHP and be done with it, but the request was to find a way to do  
it within MapServer for these (and related) reasons.

Tom's organization already has a myriad of external services that do  
this kind of thing and the hope was to find a way to reduce them, not  
expand them.

> You could use the same argument to say that we should write a  
> "mapserver
> scripting language" so folks don't have to futz about with an external
> scripting language environment.

true.  The real 'mapserver scripting language' is php anyway ... ;)

>
> Nevertheless, if xslt support can be easily (and optionally) added  
> to the
> mapserver core without undue complications then I think it would be  
> desirable.
>
> I must confess I haven't been able to follow all the discussions in  
> this
> thread, though some of Steve's early concerns about it being hard  
> to maintain
> a consistent view of a service like WFS if xslt transformations  
> have to be
> applied to capabilities, queries, results and so forth.  I'm also
> quite concerned that we not put ourselves in a box where full GML  
> results
> have to be held in some sort of memory document tree organization  
> before they
> are converted to xml.  To me this suggests applying libxml2 to WFS  
> query
> results is a problem.

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?

Cheers

Paul

>
> Sorry if the above have already been responded too.  No need to  
> answer them
> for me - I'm mostly planning to sit this issue out.  Call me a "0".
>
> 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

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+