Jody we had this discussion a couple times now and you keep telling we can model an xs:complexType with xs:simpleContent as a ComplexAttribute but I keep not seeing it that easy.
Basically, in xml any type with simple content that allows xml attributes is a xs:complexType with xs:simpleContent. say you have the xml structure: <root> <element att="attval">elementValue</element> </root> That means when you adress the element node through XPATH, say, //root/element, the result will be the element's value: the literal "elementValue". If we model such an structure as a (simple) geoapi AttributeType, the same expression would evaluate to a (simple) geoapi Attribute where the value is the literal "elementValue". By the other hand, if we model it as a geoapi ComplexAttribute in order to hold both the simple value AND the xml attributes as geoapi AttributeType/Attribute, the xpath will evaluate to a Collection<Attribute>, with an Attribute for the simple content value and an Attribute for the "att" attribute. Problem here is we don't have a descriptor for the simple content to hold on the nested attribute, nor a convention on how to call such an AttributeDescriptor. All in all, as the geoapi and xml models diverge in this regard, there will be some sort of adaptation do make at our side. That said, I agree using the attribute's userData map to hold on the attributes is bad and hacky. But I can't think of a clean solution to make //root/element evaluate to Attribute[value=elementValue, AttributeDescriptor[name=element]] instead of a collection holding both the Attribute for element and for att. Making //root/element/@att evaluate to the xml attribute modeled as a property is straight forward, what we lack is a sort of convention like //root/element/@simpleContent. In other words, if we model a xs:complexType with xs:simpleContent as a ComplexAttribute holding an AttributeDescriptor for the simple content and an AttributeDescriptor for each declared xml attribute: - how do we call the AttributeDescriptor that holds the simple content (I guess it should be called the same?) - how do we make regular xpath expressions to evaluate to this convention attribute instead of to the collection of attributes, or rather how do we deal with it not to have to introduce conditionals everywhere to check if an element contains a child element that's the xml related simple value? Say at encoding time we do have the xsd schema to check if its a complex type with simple content, so it can aid on encoding it as an xml element with simple content and attributes. Same thing at parsing time, but we still lack a descriptor for the simple content... humm... hope I explained my concern clear, may be you have a simple answer or can point out where am I wrong. cheers, Gabriel On Friday 17 October 2008 09:44:42 am Jody Garnett wrote: > 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 ------------------------------------------------------------------------- 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
