Re: [Geoserver-devel] sorry for missing IRC, here are my thoughts

[Rob A. <rob...@gm...>]

I'm all in favour of supporting XSLT, but not as an "outputFormat" -
rather as a configurable per-layer per-output format option.

XSLT would be fantastic as a stopgap to fix things or support encoding
options we want to play with but not code against, or to handle
complexity we cant efficiently handle with mappings

Rob

On Thu, Nov 27, 2008 at 7:52 PM, Andrea Aime <aa...@op...> wrote:
> Rob Atkinson ha scritto:
>>>>>
>>>>> Cool.  Let's try to come up with perhaps a specific roadmap / pitch to
>>>>> put on the GeoServer site, so we can point people at a plan, that they
>>>>> can
>>>>> help accelerate with funding.  I'll try to put some time in to this
>>>>> next
>>>>> week, perhaps we can try to pass it around on a wiki site.  I think
>>>>> Justin
>>>>> took a first crack at it, turning the stuff Gabriel mentioned in to a
>>>>> document.
>>>>
>>>> Rob may be understating things a bit; I found a couple of Australian
>>>> groups considering deegree simply based on their community schema
>>>> support;
>>>> and not entertaining the option of GeoServer.
>>>
>>> Hum, is it really because of the ability to support complex features
>>> natively, or just about the support of XSLT transformations?
>>> If GeoServer had an XSLT based output format, would that solve the
>>> problem?
>>>
>>
>> XSLT is not a solution in the long term - its slow, difficult to write
>> and will be very difficult to maintain when we have a few thousand
>> feature types in common use (eg INSPIRE).
>>
>> Also, transforming queries using XSLT requires a lot of logic, and the
>> ability to execute any feature-relationship queries seems completely
>> infeasible.
>>
>> And of course, standard SLD's can be defined against standard feature
>> types, (even if implemented as named WMS styles). So you would need
>> three complicated configurations for every feature type if you are
>> unable to model it properly internally.
>>
>> The other bit of work, the ability to plug in functions, might allow
>> you to get away with this, but that would mean re-expressing the
>> standards in terms of supported functions, not feature models. I dont
>> see this happening in the near future.
>>
>> The feedback I have from some of the people using Deegree in the
>> GeoSciML community is that would still welcome a configurable native
>> capability.
>>
>> I haven't really thought to much about the implications for WFS-T to be
>> honest.
>
> Whoa, I wasn't suggesting to use XSLT as the mapping tool. I was
> suggesting it as a stop gap measure for
> people that want to return a specific XML structure.
> I said "output format" and I mean it, everything works within
> the native type, only the output XML would be transformed (the very
> last stage in the pipe).
> And I'm not saying this because I'm particularly in love with
> XSLT, but because:
> * I've heard that in the community schema test over there someone
>  used DeeGree because they could setup XSLT transformation and
> * because a user already provided some code to make that kind of
>  output format possible, I would just need to adapt it a little
>  since the solution provided is not flexible enough imho:
> http://www.nabble.com/Adding-a-servlet-filter-for-XSL-transformation-on-WFS-gml-td19569283.html
>
> (and with XSLT one could generate whatever he wants, not only other GML)
>
> Cheers
> Andrea
>
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>