Martin Desruisseaux wrote: > I think we missed coherence in our discussion... On my side I'm really fine > about Ben applying his change, and in my mind the "pending" module was > created > for that purpose. I replied to Ben on the mailing list saying than I'm fine > with > him applying the change: > > https://sourceforge.net/mailarchive/message.php?msg_name=499BF97E.7080707%40geomatys.fr > > The only thing is that I don't know to who Ben should talk in order to > synchronize his work with GeoTools code base. > That would be me I suspect - I was in doubt about the problem. I figured if two thinks were being represented we should admit to that and make it a complex type; we did this to handle anonymous repeating xml groups and I would like to stick to our guns on this and be consistent.
I actually had a good discussion with Ben this afternoon; and think we will get back to the geoapi list after we have had a chance to confirm the direction being taken in code. There were two possibilities on the table to represent a complex type extended from a simple type (if I phrased that right): - make use of user properties to provide an indication about the extra attribute information. This would be a hack but possible since these attributes are all simple because of the way xml works. User properties are to be used by code such as the parser / encoder that wants to store some metadata around for later; using this to represent actual data is kind of crossing the line for me - make use of some kind of naming convention (such as representing this situation as a complex type with one of the attributes marked as "content" or something that is documented as representing a the context of a complex type). This would be a bit on the honour system and would depend on the xml parser/encoder knowing what was going down. Going over how the "hidden" metadata was introduced gave me a good idea. We introduced the idea to allow our xpath handling to recognize anonymous repeating xml groups and still use the same XPath expression as used for XML content. This was formally introduced into the api (even though it could be a user property hint) in order to show the readiness to cater for real world xml requirements. Combining this idea (hidden attribute) with option number two (naming convention) should do the trick with none of the side effects: - it gives us a complex type (ie it matches what is happening if we draw a UML diagram of this thing) - it allows us to flag the attribute that is being used to store the content as hidden so the XPath expression sort out correctly - a naming convention is not needed; since we are being explicit - the attribute can be of the simple type being represented (no need to introduce two types to represent what is going on) In anycase I like it; but I am really waiting to see if what Ben's take on it is; if the result is good we will chat on the geoapi list and make any changed needed (probably just additional javadocs indicating a best practice). Jody ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
