Andrea Aime wrote on 12/29/2006 01:00:32 AM:
> Rob Atkinson ha scritto:
> ...
> > 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.
Amen!
> 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?).
I think I might understand what Rob is getting at. Let me explain my
thoughts, and Rob can correct me if I'm putting the wrong words in his
mouth.
"Schema assist" is not necessarily tied to GML. Drawing out your feature
model in a UML class diagram with all the geospatial and non-geospatial
attributes is known as an "application schema". This is a quite flexible
and robust means of planning any data you intend to share, and lets you do
pretty much anything you can do when you're designing software. Your
features can have data. They can also "have relations" with each other
(associations, aggregations, and compositions). And they can have
behaviors/operations.
GML schemas deal only with the data model + associations. They are not
equipped to handle a full feature model simply because they cannot transmit
behaviors. Platform neutral behaviors can only be described to humans in
natural language. In fact, while we can pick and choose from many ways to
transport data in platform-neutral ways, there's no means currently
available to specify platform neutral behavior.
Starting from this point, it's not hard to see that the "schema" contains a
complete description of the feature, while the memory resident version of
the feature contains some part of the feature (usually the data). We have
to allow the memory-resident version to not have certain things which the
schema does have. Once we do that, we must have some means of combining
the data part of the schema with the behavior part. Once we have this
architecture in place, we could certainly apply it to missing data items.
So I think Rob has this bigger picture in mind, and "schema-assisted" is a
means of matching up a complete schema ("feature type") with an associated
in-core feature instance which has only some of the schemas attributes.
After all, if it's "the same feature" even when it lacks the ability to do
stuff, it should still be "the same feature" when it lacks a data item or
two. Data and Operations are all properties.
> >> 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!! :-)
My thoughts too.
What about this:
Define a "ViewFeature" as a GeoTools utility (as in a "view" in SQL). This
feature maintains an association with a particular feature reader and can
handle representing a particular subset of attributes. THis utility would
implement the Feature interface and GeoAPI isn't touched. You could
implement multiple attribute caching strategies in several concrete
children, or you could let the user compose the utility with a caching
strategy object at run time. Heck, in general the View could be made up
from many different source FeatureTypes. Or it could calculate values for
a field not in the original data set (or just provide a field in which to
store the results of a per-record calculation).
If reality bites the user on the head because they are using an
inappropriate data access strategy, that user needs to get smarter.
There's no cure for dumb users. We'd only need to populate the toolbox
with "likely-to-be-useful" tools.
This idea is actually the opposite of Rob's injecting/merging philosophy,
but I think it may be a more natural fit to the original question about how
to handle queries for some but not all of the data attributes. (Without
requiring major design or implementation efforts.) It's just easier to
throw data away than to try and "match up" a data fragment with an
all-encompassing schema.
> >> 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?
It could go either way depending on what the user wants to consider "equal"
at run time. They may want to ensure that all attributes corresponding to
the feature are present. They may just want to know that the data which is
present came from a particular feature type. They may not care one bit
about what feature it came from, but it must be "elevation data" or "land
cover data" or whatever.
I think making an org::geotools::ViewFeature should give the user enough
ways to figure out the "equality" they want without hiding a paticular
meaning of "the same feature" behind an equals method. Since the names
aren't the same ("ViewFeature" != userFeature) they aren't the same
feature, but ViewFeature.source() could reference the feature type which
provides the original data definition.
I particularly like the fact that GeoAPI is not touched. It should also be
a good example to library users: "see it's OK to write your own
implementation of the Feature interface."
Oh well enough for today.
Bryce
-------------------------------------------------------------------------
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
