Andrea Aime wrote: > (18.32.12) aaime: Hum, it seem the feature model review triggered a good > chain reaction > (18.32.17) aaime: but Jody is missing from the mix, sigh > (18.32.34) aaime: I guess he's the only one willing to face the > data/metadata mix issue... > (18.32.59) aaime: btw, you're here. jgarnett, when we'll see your > opinion on the matter? :) > I am still "missing" until the weekend; FOSS4G prep and a project deadline have my kind of hammered. I have started an open office document to answer your questions, (using code examples when I can). I tried to do a cost/benifit of the various features to help us out in the functinality/complexity compromise. And have a refactoring idea that can take away some of the "extra" methods (like getAttributes() and getAssociations()) from SimpleFeature - nothing earth shattering but it will help people starting out in an IDE for the first time.
I think the think the hold up comes down to the following design choice between "Multiplicity" (what we did) and "Nested Children" (what deegree did): - http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Design+Discussion From a users standpoint (someone hitting up the data structure for answers) you can tell the difference when you do xpath queries. Keeping attribute name/value paris in order allows us to model exactly what the XML is doing. Sorting the keeping attributes as name/collection pairs does not. 1- allows us to match xml 2- allows us to match xpath 3- allows us to take on observation and measurement things? (Verify with Gabriel) 4- allows us to handle data "as is" without regard for validity Point number #4 was the killer for me, I want us to be able to handle data even when it is wrong or we do not know the schema. Jody PS. Now that you understand the trade off you can see why we were not finding List to be that useful a binding, it is only useful when attribute order is significant. PPS. As I tired to find the link I realize that we have spent more blood sweat and tears on this FM thing then anything else, ever. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
