I was thinking about non-feature polymorphic complex properties. For example, CGI_Value and similar types from GeoSciML 2.0: http://www.geosciml.org/geosciml/2.0/xsd/value.xsd
The GML striping rule requires that the type (XSD element) is encoded before each property name. BindingPropertyExtractor.properties searches the substitution group to find all the valid type names, to find the properties (this is the GML PropertyType pattern). This is the first example I can think of where automatically built feature types will not be able to support polymorphism. But then, you don't need to have polymorphism to be complex! Andrea, do you have any polymorphic property types in your use case? If not, encoding becomes a great deal simpler and will likely work with Java-only types. Regards, Ben. On 09/02/11 10:51, Gabriel Roldán wrote: > Still I think it could be possible to grab a hand made FeatureType and > derive its xsd, right? Even if it may break right now, it shouldn't be > that complicated? > What do you mean the encoder needs to know about substitution groups? > can't it work if there are no substitution groups? The FeatureType > itself would be in the _Feature subs group. What else is _needed_? > > Cheers, > Gabriel -- Ben Caradoc-Davies <[email protected]> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
