Rob Atkinson ha scritto: ... >> Yes and no. The GeoAPI definition is in a no-man's land between modeling >> with OO and modeling with XML Schema. It's not exactly >> straightforward and >> I have yet to figure out how this mixing will impact our code base. >> >> The GeoAPI model reflects the fact that we're really not willing to >> commit >> to a single expression of a feature model (OO or XML Schema), and require >> all alternate expressions to undergo translation back and forth into the >> core model. THe model itself has to do everything. "Design by >> committee". >> OO vs. XML Schema: a knock down drag out fight of the titans. Little >> guys, >> beware. :) > Do you think that "schema-assisted" object model mapping is a reasonable > compromise - as long as we have the extension points to extend the > schema with object libraries - such as GML primitives, coverage > primitives, custom operations
Guys, speaking from an OO and library point of view, can't we consider XML just an I/O format? Forcing XML schema right in our object model as ways to get extra information strikes me as something we should really want to avoid. Hopefully the future will give us something easier and/or faster than GML for the most common cases. See binary protocols, or GeoJSON, GeoRSS and so on. GML is definitely the most flexible format, and our OO model should be at least as expressive as GML, but I don't see why we would want "schema-assist" it (which I may be misunderstanding, but feels like having feature types gathering extra informations from a schema?). >> If the feature reader returns a partially resolved feature, how are the >> resolved attributes distinguished from the unresolved ones? > private flag I guess. Alarm! Layering violation! layering violation! The model knows about persistence!! :-) Ok, on a more practical note, if you want to resolve extra attributes by asking the data store to gather them on demand, you're really setting up for disaster. Reality will rise its ugly head and go bite you. Let me explain. Suppose you start with lazy resolution because you feel it'll use less memory, be faster, be cooler and whatnot. You just load two attributes up front, and leave the others "lazy". Now, you SLD every 10 features triggers a rule that needs the some lazy attribute. Hypothesis 1: for each feature, a fid filter query hits the datastore to gather the missing attribute. It means that if you're loading n feature, you'll do in the end 1 + n/10 queries on your datastore. I hope you imagine how slow this could be... it'll turn your wonderful implementation into an academic toy that can't be used with real world data. Hypothesis 2: your reader is really smart, once it sees a lazy attribute is requested often enough, it'll change the query and load the extra attribute too. In this case, the code becomes a lot more complex (you have to guarantee you load the features in the same order as before, find again the position, or do an extra query and merge in-memory), and prone to just fail to properly interpret the situation and load extra stuff you don't really need. All in all, your code maintainability pays a high price. >> This seems to argue for >> considering unresolved attributes permanently unresolved, which would >> merit >> a different feature type. >> >> > I think this is not a new feature type, but maybe an error if you dont > ask for everyhting you will need, maybe its OK for the feature instance > to throw an exception if an unresolved attribute is accessed? I'd > rather correct behaviour than start managing vague definitions. This is a lot better, but it seems to me more sensible to have an extra feature type. Let's tackle this from a GML angle: you are removing attributes, maybe attributes that are mandatory in the original feature type. Hence, your "reduced" feature type is not the same as the original, the XML schema that defines it is different, no? Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
