Hi,
been working on CSW on the GeoServer side, it would be nice if someone could provide
some checks on the interface chosen to represent the service.
The methods represent as usual the various CSW methods, plug GetRepositoryItem
which is an extra method added by the ebRIM profile (and which we don’t need to
support unless there is a CatalogStore providing support for it).
The capabilites method returns a CapabilitiesType instead of a TransformerBase,
meaning we are building the in memory EMF representation of the caps document
and that we are going to encode it with XSD.
The reasons for this are:
- the caps document is limited in size
- the various profiles introduce a number of extra content in the caps document that
is literally sprinkled around in the operations and service metadata
as opposed to being in a well specified root element, so having a object to play
against makes it easier to perform open ended additions
The “decoration” could be done in a DispatcherCallback, but I guess it’s nicer if we provide
people a pluggable CSWCapabilitiesDecorator interface with a single decorate(CapabilitiesType)
method where the extra bits are added.
DescribeRecord would return a list of FeatureType objects, each representing one type
of record (csw:Record, ISO and ebRIM).
Encoder wise I don’t think we are going to turn the above into XML schema, especially
since the normal DescribeRecord response contains links to external schemas as opposed
to a full in-line description, and they are pretty much static from what I’ve seen.
Again, I expect to have a pluggable extension point that can encode the subset of the
response relative to a certain well known record type, this time playing within the
xml transformer framework (the one used for the capabilties documents of WMS/WFS/WCS
and to generate KML).
getRecords and getRecordById would return the Feature representation of records.
Again the response will be delegated to specific encoders that know how to deal with
each particular record type, and again using the translator framework
GetDomain needs to return a list of possible values for a specific request parameter or a specific
record type. Needless to say, this list might be very long, so for the time being I’ve chosen
Iterable as the return type, which would then be managed by a translator
to encode the xml response.
I’m not 100% happy with the choice in that an Iterable does not have a close method
and does not throw exceptions, so I don’t see it playing well with database backed
lists…
Another option could be to return a SimpleFeatureCollection or a FeatureIterator…
it seemed a bit heavy handed to return something as big as SimpleFeature just
to hold a string though…
GetRepositoryItem returns a RepositoryItem object, which is really just a struct containing
an input stream (the contents) and its mime type.
Harvest and Transaction are using full EMF objects on both sides: I don’t plan to implement
them now (Niels might want to implement Transaction, not sure) but believe the interface
should work for the needs of these operations.
Opinions?
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 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
