Cool, just a few last comments, confirming your analysis.
What I see here. Hibernate do not know a priori about how to bind hierarchy
of objects to relational model. We should configure it (through XML or
annotations) and charge the framework with such configuration. Is complex
feature type a thing that represents such a configuration for feature model?
I mean feature type that describes complex entity some of attribute types of
which are nested feature types? As I understand this is a complex feature
model.
Yes, but a better way of thinking about it is as its new name "community
schema support" - the feature model is governed by the data transfer
schema you are trying to support. These tend to be "complex" because
they will refer to other standard features (often), relevant metadata
(usually) and elements from other namespaces (eg gml:name) (always).
In this case, we read the XML schema to determine the feature model, and
augment it with bindings of concrete types to abstract types where the
schema has generalised elements.
I did not follow a lot to complex feature model discussion. But if
there is a such configuration (like complex feature type) then there is a
way to implement complex features binding to database relational data model.
We are currently doing the binding in a wrapper data store, with limited
functionality. I think that we could probably support most of the
binding more elegantly with a stronger JDBC data store, based on the
full feature model. Only truly complex features should need a wrapper,
where there are multi-valued complex attribute types, or joins to
related feature types that share configurations.
We charge the framework with configuration of complex feature types, binding
starts to work. So, as I understand, this is mostly about configuration, how
to model complex relationships, then complex features binding implementation
may be general enough to work with any general configuration. Like we
provide XML schema and XML document begins to be not only text, but
structural information for third parties (parsers e.g.)
Possibly this can/should be abstracted to a different level of the
architecture, but keen to see whether you have thought about this at all.
When there is no user provided configuration described above, the only SFM
is available for JDBC features binding (table to feature type, row to the
feature) in automatic way. If there is a general mechanism to model complex
relationships then we may implement more complex binding. But I am not aware
about complex feature model progress a lot. So, that's why my understanding
of these things are intuitive right now.
just the ability to map SFM into multiple namespaces, and to choose the
elements from the table, and to be able to invoke functions and joins
would help enourmously, and would suit many simple schemas without
further capability (Simple Features Profile Level 0)
begin:vcard
fn:Rob Atkinson
n:Atkinson;Rob
org:Social Change Online
email;internet:[EMAIL PROTECTED]
title:Principal Consultant
tel;work:+61 2 42265490
tel;cell:0419 202 973
x-mozilla-html:TRUE
url:http://online.socialchange.net.au
version:2.1
end:vcard
-------------------------------------------------------------------------
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
