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.
Here is its:
https://github.com/geoserver/geoserver/blob/master/src/community/csw/csw-core/src/main/java/org/geoserver/csw/CatalogService.java
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<String> 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
-------------------------------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
