Adrian Custer wrote: > As I understand Martin's vision, users are not forced to even think > about the annotations, which users can happily ignore. They are > annotations, not code, and invisible in the javadoc. I am not that worried about annotations; except that we want to bind the same beans to two schemas (ie Filter 1.0 and Filter 1.1 as the example). For things like metadata class where there is one schema we could get away with it ... > 2) Those who wish to target or support multiple formats have more work and > will have to use either Justin's parser work or write code following Jody's > suggested DTO work. Both will work happily against the annotated base class. > Um so how do you decide what format the annotations support? As we migrate to Filter 1.2 all the other uses would break right? > So the Java code works for everyone, there are two approaches for highly > complex parsing of different formats, and one default for the lazy mortals > that need one serializable format and are willing to settle for "whatever SUN > cooked up for us". > So what is Suns plan for supporting an evolving format? I don't have a lot of hands on time with JaxB but they should have something right? Jody
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
