Hi Andrea, Thank you for your response. I will try to add more explanatory notes to the proposal when time permits. I considered making several smaller proposals but decided against it as I didn't think the task lent itself to being broken up; the individual components wouldn't have any utility on their own... they only made sense in light of each other. I'll happily stand corrected if others disagree with that choice, though?
With regards to your comment on the "Public API to Make a WFS Request": I hadn't actually considered making the *Access classes return Simple types too but I can see the value in having a class that can deal with both Complex and Simple types. I will investigate this further. The new parameters (GML_COMPLIANCE_LEVEL and SCHEMA_CACHE_LOCATION) are used by the *Factory classes to find an eligible DataStore/DataAccess. They are both optional: GML_COMPLIANCE_LEVEL is only used if it set, and SCHEMA_CACHE_LOCATION can be omitted, causing the AppSchemaResolver in WFSContentDataAccess to simply not use a cache. I agree that "append" should be used for multi-valued properties, that was my intention so I'm glad that's what it made you think of! :) With regards to your question about how to builder should go about constructing nested structures and lists: I'm open to suggestions from the community on this. I'm still in the process of working out what the best approach is. I started looking into some validation but ran into problems with cyclic references in certain types (by that I mean, where two features both refer to each other); for this reason I must be able to create a technically invalid feature first, then create the second feature, then link the second feature to the first. I'm not sure if this is the sort of thing you're referring to? Either way, I will make any deferred validation optional. My intention is to use converters in the same way as the XMLSimpleFeatureParser. Now, to answer your questions about the diagrams: * Do you think it would be better to have WFSDataAccess implementations that can handle both Simple and Complex features to avoid having to create two versions of each? * ContentDataAccess: It might be possible to create a ContentDataAccess hierarchy alongside the ContentDataStore one. I put a note under that diagram highlighting this possibility, but I didn't know if it would actually be better to make ContentDataStore and DataStore more generic so they don't impose a restriction on SimpleFeatures at all? I'm open suggestions... * The changes I've made to SimpleFeatureBuilder are limited to making it extend from FeatureBuilder<SimpleFeatureType, SimpleFeature>. There are no changes to its actual API. Please let me know if anything is unclear or if I've misinterpreted something you've said. Thanks again, Adam -----Original Message----- From: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] On Behalf Of Andrea Aime Sent: Sunday, 10 June 2012 5:11 PM To: Caradoc-Davies, Ben (CESRE, Kensington) Cc: geotools-devel@lists.sourceforge.net; Brown, Adam (CESRE, Kensington) Subject: Re: [Geotools-devel] API Change Proposal: ComplexFeature Parsing & Building Support Hi all, have been looking at the proposal, I have to say I'm finding it difficult to read as it crams into a single proposal a number of changes that can be related togheter only under the assumption that one is making a new wfs data store, and as such they do require some familiarity with how the store works (of which I don't have full grasp). About the "public api to make a wfs request" portion, care should be taken to preserve simple feature usage when possible. E.g., even if the store is a data access it should keep on building simple features and returning SimpleFeatureCollection when the remote type is simple. Which actually seems the direction you're taking when I look at the diagrams, but I'd like to make sure :-) About the new parameters, will they have sane defaults so that one does not need to specify them when hitting a simple feature server? Looking at the complex feature builder the "append" method makes me think about multivalued properties, e.g., something that I could call repeatedly over the same attribute to build the collection of values associated to a property. If it's not meant to be used like that I'd say keep on using "set" would be better, which is already available in the simple feature builder and takes a name (either String or Name). I agree "add" is probably not suitable since it assumes an attribute ordering that in complex features does not appear to be there. Complex features wise we have nested structures and lists, wondering how the builder is going to handle/help with that? Does it make sense to spawn a sub-builder that takes care of assembling a sub-feature or a list of them? I don't see mention of the validating/non validating behavior that SimpleFeatureBuilder has (and which is off by default). We had a long debate over that and concluded validation should be optional, are complex features departing from that? (I actually don't remember exactly why validation was turned off, just remember it was tried out and it did not work in practice). Ah, wondering if the complex feature builder is using converters when setting values like the simple feature builder is. Pretty much all data handling in GeoTools is geared towards trying to "accomodate" first, eventually complain later if adapting is not possible. Looking at the "changed type hierarchies" diagrams: - I see there is a wfs data access factory and a wfs data store factory. How is this going to be played, will we have a complex and a simple wfs data store in parallel? (with the differences in versions one might end up having 6 different store implementation, 1.0, 1.1 and eventually 2.0, simple and complex, ugh...) Also have a look at DataUtilities.simple(...) methods, they can be used to bridge the two worlds in case the contents are simple features (although there is no method to bridge a data store) * DataAccess type hierarchy changed to accommodate WFSContentDataAccess --> does this mean we won't have a ContentDataAccess hierarchy, but just a custom implementation for WFS? * Nice to see the complex and simple feature builders share code.. wondering, will there be any change in the SimpleFeatureBuilder API as a result? Cheers Andrea ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
