Well it definitely belongs together I think, building features from xml and building feature types from xsd.
On 11/13/2012 04:53 AM, Ben Caradoc-Davies wrote: > Niels, > > that sounds great! > > What is the overlap with Adam Brown's complex builders in his > ComplexFeature Parsing and Building Support proposal: > http://docs.codehaus.org/display/GEOTOOLS/ComplexFeature+Parsing+and+Building+Support > > > > I think this is still resting in a branch in Adam's github repo. > > See yesterday's committee meeting notes: "Reference point: Andrea had > to make layers of builders in order to use this kind of setup for CSW > (ebRIM record, CSW record). Used Adam's Builder, and then builders on > top of that domains specific." > > Adam? > > The long-term goal should be to break-out all the complex builders > into gt-main (or gt-complex if not possible) and then refactor > everything (including gt-app-schema) to use them. And have great API > user documentation and example. > > Kind regards, > Ben. > > On 12/11/12 19:35, Niels Charlier wrote: >> Hi Ben and mailing list, >> >> I would like to propose that some of the stuff in the app-schema module >> gets taken out of the app-schema module, and move either in a new module >> or into an existing module. >> >> The issue I am dealing with now is that I need to use a bunch of stuff >> from app-schema that has to do with complex features in the CSW module, >> but it doesn't actually have anything to do with app-schema itself at >> all (application schema mappings etc). >> In particular >> - Creating complex feature types and features from scratch. >> - Certain parts of the feature type registry, in particular the creation >> of feature types from xsd schemas. >> - The complex feature property accessor, which makes it possible to >> retrieve properties from features with namespace qualified advanced >> x-paths in filters etc... >> >> In my view these things are really something separate from all the rest >> of the stuff that is used to support the application schema mappings >> specifically. Separating these concerns has a number of advantages: >> - A module like CSW can use these features without relying on a whole >> module of which most of the stuff really has nothing to do with it. >> - People can easily implement other implementations of complex feature >> stores or other things that use complex features without having to use >> app-schema. >> >> For now I have created a separate gt-complex module on my repository >> https://github.com/NielsCharlier/geotools branch csw, you can look at it >> for what I am going for. It contains mostly copies of app-schema >> classes, with the exception of the featuretyperegistry which has been >> made app-schema and gml independant, but in such a way that the >> app-schema specific featureregistry could easily be built on top of it. >> >> My preference would be to create a new module; because it has the >> advantage of the clarity. You would get all the complex stuff together >> (because they are spread among different existing packages and can't be >> put in one package) and it would be easy to adapt app-schema to use it. >> >> Thoughts/ideas? >> >> Kind Regards >> Niels Charlier >> > ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
