Ben Caradoc-Davies wrote:
> Justin Deoliveira wrote:
>> Ben Caradoc-Davies wrote:
>>> (1) How do I register a second binding for GML.AbstractFeatureType 
>>> when one already exists? If I do this, many unit tests break.
>> You will have to override it. What I would expect to see is a separate 
>> Configuration instance for "complex GML", which re-uses much of the 
>> non complex stuff. In the complex configuration a different binding 
>> will be attached to GML.AbstractFeatureType
> 
> This is what was done in the GeoServer 1.6 community-schemas fork. The 
> problem is that if there is a separate GML configuration for complex 
> features, there will have to be a separate WFSConfiguration, and a 
> separate GeoServer release with complex support. I suspect this is why 
> all the binding overrides lived in the GS repo, not GT: to be near the 
> substitute WFSConfiguration.
Hmmm... I don't see it this way. I mean... every in geoserver there is 
now the decision, if simple feature so this, if complex feature do that. 
I don't see why it cant be the same for GML encoding. If simple feature 
use the regular WFSConfiguration, if complex use the complex one. They 
will share mostly the bindings... except for AbstractFeatureTypeBinding, 
etc...
> 
> I can see no reason why GT should not be improved to be able to process 
> both. This would give us a single GT/GS stack for both simple and 
> complex. Plug in gt-app-schema.jar, configure your app-schema DataAccess 
> connection parameters, and go.
> 
While i agree it would be nice to have a single entry point, having both 
cases handled in the same place makes things overly complex. I would 
tend to start seperated... and merge once we have the final picture of 
the complex case looks ike.
> I am very close. Only property types (and a few other bugs) stand in my 
> way. I was also getting close with a PropertyExtractor, but it seemed to 
> make a huge mess ...
> 
>>> (3) How do I write a binding for GML types whose name is not known at 
>>> compile time? In my earlier example GeologicFeaturePropertyType is a 
>>> complex type defined in an application schema.
>> The binding will have to be dynamic in nature, like 
>> AbstractFeatureTypeBinding is today. It does not not know what actual 
>> feature type it is parsing, it looks it up dynamically basked on the 
>> element actually being parsed. Although it uses a fall back to get 
>> around the fact that most people do not ever specify there application 
>> schema properly.
> 
> What is the base type of a complexType that extends nothing? 
> XS.COMPLEXTYPE? For example:
> 
>         <complexType name="GeologicFeaturePropertyType">
>           <sequence minOccurs="0">
>                <element ref="gsml:GeologicFeature"/>
>            </sequence>
>            <attributeGroup ref="gml:AssociationAttributeGroup"/>
>        </complexType>
All types extend from xs:anyType.
> 
> It seems Encoder ignores the content of this at the moment, perhaps 
> because of the ref to an abstract type. Is this an Encoder bug or a 
> missing binding?
> 
Well... the only binding that would engage in this case would be 
XSAnyTypeBInding. And yeah, it does not implement any of the 
getProperty() methods, so essentially ignored.

>> But if you look at the class and follow it down you will eventually 
>> hit the method:
>> GML2ParsingUtils.featureType(XSDElementDeclaration element,
>>          BindingWalkerFactory bwFactory);
>> This is the method that takes an xml element declaration and from its 
>> type builds a feature type from it. I imagine you will have to write a 
>> complex version of this method which handles complex content.
> 
> I avoided this when I avoided fixing SimpleFeatureTypeBuilder.  :-)
> 
> Fortunately, I am trying to encode only (no WFS-T). I do not have to 
> parse incoming XML or create simple types on the fly.
> 
> Kind regards,
> 


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to