Ben Caradoc-Davies wrote: > 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. I agree, there are are many places where the assumption of a non-qualified name is assumed. While in the simple case this is a reasonable assumption, having the simple case work with Name is not a huge hassle, so probably doable. > > 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. > Ha, you should have seen things before they were around. The "bloat" and "cruftyness" are a result of maintaining 10 years of backward compatibility. Unfortunately its hard to keep that pretty. > 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? > Yes, but my experience with changing apis over to Name is that much of it can be done in an additive way. The only pain is occurs when a class returns a list or array of String, and now we need name. > (2) How should it be done? (I am looking for suggestions of where to > start, and other areas that will need work.) Query seems to be a logical place to start perhaps. I would say add the methods necessary to keep in tact the qualified property names and types names passed into the query. > > (3) Who is able to help? I am happy to review any patches. As with the geoserver changes, I would like to see a patch representing a "spike". Apply it so i can review and provide additional feedback. > > Kind regards, > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
