quick - pre-dawn jet-lagged response - I'll re-read after breakfast and coffee ..
Thanks Justin - this sounds great - well done. How can we get a look at the solution so far? Once we have an approach to maintaining the code the AusScope team can kick in to worry about handling the wierd cases. If you look at AbstractSimpleContentTypeBinding you will see Ben's implementation of the simplecontent type, along the lines you suggest. This is recognised as a hack though. The problem is that GML3 does not actually follow the ISO19118 encoding rules - "pragmatic" concerns crept in an people preferred using attributes in arbitrary places to make it more human readable. We are paying for the complexity introduced by the mantra of keeping it simple - you pay more in the long run if you dont have an understanding of the inherent complexity of a problem. So, a type has properties in the UML (or model) that are attributes associations operations It may also have constraints, and tagged values which are implementation hints. We cant use this now, but it may provide some comfort if we imagine we had these available for the GML model. One key tagged value is called inlineOrByReference to force encoding rules. The XML encoding basically has: scalar attributes - capable of handling scalar valued attributes simple content - capable of handling an arbitrary choice of a single scalar valued attribute elements - capable of handling complex typed attributes and associations in GML schema, most elements have generic a GML attribute group that allow a byReference (using xlink) implementation. It is important the model respects this, so the implementation can control it to determine the choice, if it is not set by the taggedValue. In GML, by default, the taggedValue is not set, allowing either to be valid. In analysis, there is probably no mapping from the choice of simpleContent in the GML schema to which attribute in GeoAPI - which reflects the ISO model. So, it is perfectly reasonable to annottate the schema - in this case Justin you say you have hacked it - maybe an out-of-band configuration - an annotations file would be even cleaner - I think it fits in architecturally to the UML/GML mapping and hence the GeoAPI/XSD schema mapping problem. FYI, "application schemas" that we will be focussing on in AuScope, and INSPIRE and other key standardisation efforts use UML models, compiled using ISO19118 and are more regular than GML3. I have recently spent some time deep in the ISO model loking at topology for hydrology modelling, and it is a realm of mathmatical elegance and brain-sapping abstraction. I hope to have a chance to look at this myself in the medium term. On Sat, Sep 5, 2009 at 3:56 AM, Justin Deoliveira<[email protected]> wrote: > I have made some progress toward getting the encoder to consume generic > ComplexAttribute instances (http://jira.codehaus.org/browse/GEOT-2505). > > I have modified the code generator so that it can actually handle the > madness which is gml3, and spit out a Schema object which has all the > types from gml represented as geoapi feaure model types. Complete with > attributes. This was no easy task due the circular nature of GML. And > what comes out of the code generator is not complete and requires some > manual tweaking. Actually in doing so this was the first time I ever saw > a java complier spit out the error message "static initializer block > exceeds 65535 byte limit". Yikes. > > There was also the problem of how to resolve the circular references > (all the topology and temporal stuff in gml is riddled with them). To do > so i had to comment out the contents of some of the types. At some point > the generated geotools types will have to be manually tweaked to re-add > them in. > > I have also tweaked the parser to ignore the regular type binding system > in cases where a generic ComplexAttribute is passed in. In doing so I > created a special binding for ComplexAttribute which targets the type > XS.AnyType (the root of all types). The implementation of this binding > is far from complete, at this point it is just a proof of concept. > > To move forward I need answers to the following questions: > > 1) How should attributes be represented? It seems the answer is that > they are just regular properties. This relies on the encoder being able > to figure out which properties are elements, and which are attributes. > This is the approach i have adopted in my proof of concept. > > 2) How should complex types with simple content be represented? Jody has > said/suggested that this be a property with the name "value", which is > marked as inline. I think that can work... there will just have to be a > another special case in the encoding logic which will use the "value" > property when it detects the complex type simple content case. > > However the feature model is incomplete in this regard. > ComplexAttribute.isInline() is never set (there is no way to set it) and > it always returns false. > > 3) Sync up with Ben on the generic complex attribute binding, as I know > there are bits of this logic already in place. > > -Justin > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
