Ben Caradoc-Davies wrote: > Jody and Justin, > > I am having trouble understanding the use of GeoAPI 2.2 > ComplexAttribute, particularly for complex types with simple content. > As I noted earlier, GML3 on trunk binds every ComplexAttribute, > including CodeType, to Collection. I now suspect that my problems are > in GeoAPI 2.2 (or my understanding of it), not just in the GeoTools > GML3 implementation. The thing is - it is a collection of Property. With that you have a pretty wide range of expression: - Since Property can be an Attribute or Association - You can repeate Property entries (if maxOccurs is greater than 1) - Property acts similar to a Key Value pair in a Java Map; it is just that the keys used are a bit more formal > Here is a concrete example. gml:name is a gml:CodeType, which is an > xs:complexType with xs:simpleContent that extends xs:string and adds a > codeSpace attribute. For example: > > <gml:name codeSpace="urn:x-something:whatever">SCOPED_IDENTIFIER</name> That sounds fine, something to consider that since this is a formal vocabulary you may already have a formal CodeList defined for the "x-something:whatever"; that is you may already have a binding for the type that is non String. > In the old GeoTools 2.4.x community-schemas feature model (fm), based > on geoapi-nogenerics 2.1.0, ComplexAttributeImpl had a value (any > Object) which would have in this case been the string > "SCOPED_IDENTIFIER", and the codeSpace was smuggled in a user-data map > and unpacked at encoding time by some horrible binding override. > > In GeoAPI 2.2, ComplexAttribute has a value that is a > Collection<Property>. The codeSpace could be a Property in this > collection, but where should the content string "SCOPED_IDENTIFIER" > go? Or am I barking up the wrong tree? You should have an Attribute in your Collection; that contains the value "SCOPED_IDENTIFIER"; the attribute descriptor should have the name "gml:name", and the AttributeType (for that descriptor) should have information about the binding (is it String; or is it a CodeList?). There is a Map in one of these data structures that you can use you can use to stuff the "urn:x-something:whatever" into for safe keeping if you want to remember it for later.
Please consider the Attribute to be a Key / Value pair - the Key is the Attribute Descriptor (ie gml:name); they key also is of a specific type (indicating the value is forced to be a String). The value is going to be SCOPED_IDENTIFIER. > Does GeoAPI 2.2 support xs:complexType with xs:simpleContent? Your above example did not really need anything beyond attribute; do you have any other entries in your complex type? > How would you model my gml:name example in GeoAPI 2.2? > > In a nutshell, the problem appears to be that XML allows a node to > have content and attributes/children, while GeoAPI 2.2 allows only > attributes/children (properties). I hear what you are saying; even if the above example I am mostly focused on the value. Have a look at which one of the data structures has a Map for you to put the codeSpace= entry into? I think you are the first person I have talked to wanting to address this issue. > As an aside, do you have any examples showing how XML documents should > be converted into GeoAPI 2.2? There are some minimal snippets in the > javadoc, but these cover few cases. > In the wiki; Gabriel has some examples (but they may be dated). Jody ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
