Jody and Justin, I have been investigating the changes needed allow the existing GML bindings to be used to encode complex features. While I am pleased with how far I have been able to get with some hacked-up prototypes, there are significant problems that remain, and many involve namespace handling.
I would like your advice, and the advice of the rest of the community, on how to proceed. The namespace problems are rooted in the assumption that every data source has a single namespace, and that all features and properties derived from it exist within this namespace. This simplification does not apply for XML in general. Gabriel hinted at this history when I implemented GSIP 31 (GeoServer migration to DataAccess API). I am now beginning to realise the implications. Principally, the consequence is the wide-ranging use of String to identify properties, with the assumption that a non-scoped name is sufficient as a unique identifier. The existence and spreading use of Name makes it clear to me that the problem is recognised; all that remains is to migrate all APIs to use Name rather than String to identify properties. Presumably, the community would rather like it if GeoTools continued to work with simple features, so I have attempted to make changes in a backwards-compatible manner. One of the things I am trying to do is to make changes that improve the existing codebase, rather than forking or adding new code to work around problems. To this end, I have been looking at the existing GML encoding support. For example, I have found that there is an undocumented contract between GML2EncodingUtils and the users of SimpleFeatureTypeBuilder. It appears that SimpleFeatureTypeBuilder accepts only String property names, so clients discard namespaces, and no-namespace properties are created, while GML2EncodingUtils gets properties ignoring their namespaces at encoding time. These two complementary fudges cancel out for common use cases, but fixing GML2EncodingUtils to respect namespaces (required to support complex features) causes many uses of SimpleFeatureTypeBuilder to fail. SimpleFeatureTypeBuilder and its best friend AttributeTypeBuilder are most kindly described as bloated and crufty. Even after hacking SimpleFeatureTypeBuilder to be Name-based with backwards-compatible support for String names, I still run into problems. For example, the Query API forces all property names to be Strings, losing namespace support, and breaking unit tests. I do not think that this can be fixed without breaking backwards compatibility of the Query API. It is a big mess. It seems to me that GeoTools requires wide-ranging backwards-incompatible changes to better support namespaces. This may cause inconvenience to those who have code based on GeoTools. (1) Does the community want to see such a change? (2) How should it be done? (I am looking for suggestions of where to start, and other areas that will need work.) (3) Who is able to help? Kind regards, -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
