Hi Justin,
can you explain me why WFS 1.1 GetFeature GTXML binding is so different than the 1.0 one? If I have to make versioning parsing for both 1.0 and 1.1 requests (in my case GetLog and such), have I to duplicate the
binding like basic WFS (not very nice)?
Cheers
Andrea
Well if you look at the schema definition of a 1.0 "GetFeatureType" vs a
1.1 "GetFeatureType" there are some significant differences:
* 1.1 extends a base class while 1.0 does not. While the end result
looks similar the binding structure is tied to the schema structure. All
the attributes that are factored out into the common base type will be
parsed by a seperate binding.
* 1.1 adds a number of attributes, resultType, traverseXlinkDepth, etc...
I agree with you that the duplication is undesirable. However, you have
two versions of an xml format, and a single internal model. It kind of
makes sense to have to sets of bindings around that map to the model.
The alternative is to have if then logic in every binding.
However there is room for binding reuse. Take filter 1.0 vs filter 1.1
for instance. Pretty much identical minus a few additions in 1.1. So you
will notice that many of the 1.0 bindings are reused for 1.0 parsing. A
similar approach could probably be used for a lot of the wfs 1.1 bindings.
-Justin
Andrea Aime wrote:
Hi Justin,
can you explain me why WFS 1.1 GetFeature GTXML binding is so different
than the 1.0 one? If I have to make versioning parsing for both 1.0 and
1.1 requests (in my case GetLog and such), have I to duplicate the
binding like basic WFS (not very nice)?Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,45f674c96162223018498!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org