Gabriel Roldan wrote:
> Right. Yet, at encoding time, since geometry bindings are special, they
> follow the property/Object pattern implicitly and take the_geom as
> _being_ of type gml:PointPropertyType:
[...]
> If the bindings (or the encoder) weren't assuming all and every GeoAPI
> geometry attribute is to be encoded as a propertyType the output would
> just be <the_geom><gml:pos>.... as it is for any other primitive type
> attribute.
> I think Ben is trying to get the encoder that smart for all the cases...
Exactly. The GML encoding spec requires that every conformant schema
follows the propertyName/PropertyType/ pattern (Simon calls this
striping), and we should be able to deduce which XSD types follow this
pattern. They are all a complex type with a single minOccurs="0" element
defined by reference. Once we can recognise the XSD layering, we can
reverse-engineer the UML model.
They look like this:
<complexType name="FeaturePropertyType">
<sequence minOccurs="0">
<element ref="gml:_Feature" />
</sequence>
<attributeGroup ref="gml:AssociationAttributeGroup" />
</complexType>
<complexType name="GeologicEventPropertyType">
<sequence minOccurs="0">
<element ref="gsml:GeologicEvent" />
</sequence>
<attributeGroup ref="gml:AssociationAttributeGroup" />
</complexType>
<complexType name="GeologicFeaturePropertyType">
<sequence minOccurs="0">
<element ref="gsml:GeologicFeature" />
</sequence>
<attributeGroup ref="gml:AssociationAttributeGroup" />
</complexType>
> but I disagree there's no more separation of concerns. You have your
> object model, coming from your database tables and the relationship
> between them, and the mappings app-schema datastore process provide for
> that separation of concerns? sort of, in the end you _could_ have a
> simpler GeoAPI model that maps to a more complex one _at encoding time_.
> Sort of moving the type mapping from the app-schema datastore to the
> encoder, right Ben?
Not quite. The table to GeoAPI mapping would be simpler, but encoding
decisions such as by reference or value would be done at encode-time.
Like an SLD for WFS.
> Imho that would lead to just moving where the
> coupling is tighter that it should... why do the encoder should be an
> encoder and also a type mapper? And then, where are you going to
> "unroll" queries against the target schema to the underlying data model?
The problem now is that we are losing information. If a user wants to
encode a property by reference, they have to mangle the GeoAPI objects
to have ClientProperties not content. This makes queries on properties
of properties rather tricky. (Rini has implemented a special case that
allows this when feature chaining.)
What I would like is for users to query against the information model,
and not have to change their query depending on the encoding.
For example, if a MappedFeature has an inline specification they might
have to query
specification/GeologicUnit/name EQUALS urn:cgi:feature:GeologicUnit:123
but if the MappedFeature has specification by reference then their query
becomes
specificat...@xlink:href EQUALS urn:cgi:feature:GeologicUnit:123
In my view, they should always be able to do the former, that is query
the information model, rather than make queries against a particular
encoding.
I would rather
(1) build GeoAPI objects that follow the UML model from tables
(2) encode them as a separate stage.
This would allow feature types to be defined that nest each other, but
have their own properties by reference when nested.
Another reason I want a simpler model is to to aid GUI configuration and
polymorphism.
> Note the current design, conceded it builds a GeoAPI FeatureType as
> complicated as the target schema, also allows to "easily" run complex
> queries against the target schema, otherwise we could as easily have
> gone with XSLT for the encoding part...
I was thinking of a jxpath configuration that knows how to follow the
striping rule and deduce types from it. The encoder tries all the
possible XPaths, and the GeoAPI objects provide what they have.
I cannot yet prove that it can be done. :-)
> That said, if there's a simpler way of doing things I'm all ears, it's
> just a matter of where all the two-way magic happens.
That is a very good question. I do not know myself, but the more I argue
this case, the more I understand and the more it seems to make sense. I
just need more people to contradict me and check to see whether I am
barking up the wrong tree. :-)
Kind regards,
--
Ben Caradoc-Davies <[email protected]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
