Hi,
wanted to recap a bit the XSLT module basics before starting to code it.
So, as we said in precedence, XSLT will be a WFS output format generator like
the ogr module.
The basic needs are to have server wide output formats generated like that
(which would be thus independent of the GML contents being transformed),
community feedback demanded it to have a per layer too, which makes sense
since transformations might need to pick on specific attributes as well.
Configuration wise, we'll store the xml config files in $DATA_DIR/wfs/xslt,
using an approach similar to the one of the styles, that is, two files for
each transform:
- myTransform.xslt
- myTransform.xml
where myTransform.xml will be a XStream dump of a TransformationInfo object
(which looks like a CatalogInfo object in case in the future we want
to make this core).
The xml file will contain:
<TransformationInfo>
<sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>
<outputFormat>text/plain</outputFormat>
<fileExtension>txt</fileExtension>
<fileName>myTransform.xslt</fileName>
</TransformationInfo>
whereas a transformation specific to a feature type will look like:
<TransformationInfo>
<sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>
<outputFormat>text/plain</outputFormat>
<fileExtension>txt</fileExtension>
<fileName>myTransform.xslt</fileName>
<featureType>
<id>FeatureTypeInfoImpl-47cc14ea:13942f810c2:-8000</id>
</TransformationInfo>
in order to link to the layer in a way that's layer rename safe.
REST wise we'll allocate the transformations in:
/rest/wfs/transformations/<myTransformation>
Justin suggested we should also have transformations under a feature type
if they are related to it:
/rest/workspaces/.../featureTypes/<featureType>/<myTransformation>
I can go for this as well, although I'm a bit worried about performance,
to do this operation we'll have to scan all configuration files in order
to determine which ones are related to a particular layer, if any
I also guess that under this setup the layer specific transformations would
not appear at the top level... or not?
Perf wise we could keep a cache of the config files in memory, and just
scan the file system to determine which xml files are there, so that
we avoid reloading them often.
All good?
Cheers
Andrea
--
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
