humm may the answer be that AttributeType needs a getAssociations():Collection<AssociationDescriptor> so we can model the xml attributes of an xs:complexType with xs:simpleContent as associations?
This also made me question the hineritance relationship between ComplexType and AttributeType for a while, in xml they're siblings, but I don't think we should escape from it now... Gabriel On Saturday 18 October 2008 01:15:57 pm Gabriel Roldán wrote: > 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
