Seems like a good amount of code. And does bring along a few dependencies
as it seems.
* xpp
* app-schema-resolver
So perhaps a new module is the way to go. But also would be fine with
rolling it into one fo the existing modules.
The second dependency is an interesting one. If this module is going to be
factored out of app-schema perhaps so should the resolver as well..
although i know its already its own module seems a bit wierd to have the
dependency back.
-Justin
On Mon, Nov 12, 2012 at 5:14 AM, Jody Garnett <jody.garn...@gmail.com>wrote:
> Hi Niels:
>
> You have identified one of the ideas I put together for this Friday's code
> sprint (http://wiki.osgeo.org/wiki/FOSS4G-AU_2012) - My motivation was to
> set up some base classes allowing for complex features to be processed -
> since as you point out there is very little available now.
>
> My preference would be to add the base classes to gt-data?
>
> --
> Jody Garnett
>
> On Monday, 12 November 2012 at 9:35 PM, 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
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
