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 > -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ 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 GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
