Weekly meeting:
- what is up
- contact commiters
- bbox
- data access
- jaxb annotations
groldan: ah, it seems codehaus decided to get back to business just for the meeting time, to be sure I can't get the proposal ready for the meeting...
jgarnett: well start typing
jgarnett: go gabriel go
groldan: doing it in a sprint.. yeah
jgarnett: well lets start an agenda
jgarnett has changed the topic to: 0) what is up
jgarnett has changed the topic to: 0) what is up 1) contact commiters
desruisseaux: 2) (minor data) standard argument ordering for envelope / bounding box
desruisseaux: (typo: minor question)
groldan: N) DataAccess proposal to enable complex feaures
groldan: (by N I mean keep the topic being the last one so I update the page on the fly)
jgarnett has changed the topic to: 0) what is up 1) contact commiters 2) bbox
desruisseaux: 3) JAXB Annotations on metadata
jgarnett has changed the topic to: 0) what is up 1) contact commiters 2) bbox 3) data access
aaime [n=aaime@host195-44-dynamic.3-87-r.retail.telecomitalia.it] entered the room.
aaime: Hi
jgarnett has changed the topic to: 0) what is up 1) contact commiters 2) bbox 3) data access 4) jaxb annotations
jgarnett: hi andrea
aaime has changed the topic to: 0) what is up 1) contact commiters 2) bbox 3) data access 4) jaxb annotations 5) coverage evolution
jgarnett: well lets get this game on ...
jgarnett: 0) what is up
jgarnett: jgarnett - patching jts 1.9 with axios code (really!)
desruisseaux: Martin: trying to figure out why JAI's "Piecewise" operation (an optimization in the "sample to geophysics" transform) produces different numbers than what I would expect...
simboss: (can you tell something about afterwards, I had similar problems this summer...)
desruisseaux: (thanks Simone)
***aaime dying to get 1.6.0 out, and working on some paid stuff
sfarber [n=sfarber@88-149-177-23.static.ngi.it] entered the room.
Eclesia: Johann sorel : selectableMap2D and editableMap2D nearly finished
groldan: gabriel: getting FGDC sample WFS 1.1 server rendered in udig and setting up proposal to enable complex features on trunk
jgarnett: wow that sounds busy!
jgarnett: 1) contact committers
jgarnett: I sent an email out; lists the handles of committers who I have been unable to contact.
chorner: looks like some udig committers on there
jgarnett: Some people I know (like IanS) but have been unable to find a recent email address for.
jgarnett: I had Jesse go through the list; if you recognize anyone please let me know and I can move their name.
jgarnett: (just send me a reply to that email)
jgarnett: and thanks!
mgrant left the room (quit: Excess Flood).
chorner: deslinger can be removed
chorner: (summer of code - udig)
chorner: anyhow... assuming this is going to email
jgarnett: cool.
jgarnett: that is all; I need everyones help on this one.
jgarnett: 3) data access
desruisseaux: We skipped 2?
jgarnett: doh!
jgarnett: 2) bbox
jgarnett: (bad jody no cookie)
desruisseaux: Do I'm right in assuming that argument is usually (xmin,ymin,xmax,ymax) except it JTS?
desruisseaux: (or width,height)
jgarnett: not really; x,y, w, h is even more common.
aaime: You're correct but... did that interface get out before 2.4.x?
jgarnett: I would write the constructor off as a lost cause.
desruisseaux: GeographicBondingBoxImpl constructor is there since 2.1
acuster: boxes are 3d; rectangles 2d
desruisseaux: Thats the ISO name and is 2D...
jgarnett: lol; that makes sense - I never got that before.
aaime: if it has been there for so long, I would not change it
aaime: but add an alternate constructor with 2 points instead
desruisseaux: The question is related to what should be ordinates order in toString() output
aaime: make the tostring output a little more verbose and unmistakeable maybe?
desruisseaux: yes all right, but still which order?
aaime: (xl: 0, yl: 0, xm: 10, ym: 20)
aaime: I'd say xmin, ymin, xmax, ymax, I agree that it's more readable
desruisseaux: I'm fine with that, so this means changing the order of current GeographicBoundingBoxImpl.toString()
jgarnett: aaime++
aaime: it's just that breaking the code in a way that does not even break compilation is subtle
jgarnett: ( xmin - xmax, ymin - ymax ) is a good alternative; use '-' to represent a range rather than a comma.
desruisseaux: Well, maybe I will write a wiki and ask what peoples wish. My wish was just to have a consistent approach in Geotools
desruisseaux: I'm done (will write a wiki or something else)
desruisseaux: 3) data access
aaime: what is this?
groldan: mine
jgarnett: gabriel ?
groldan: http://docs.codehaus.org/display/GEOTOOLS/Data+Access+API+for+ISO+Coverage+and+ISO+Feature
groldan: ok, sorry I didn't get it done for the meeting time
groldan: yet it deserves some discussion
jgarnett: should rename it so it does not mention coverage
groldan: indeed
groldan: the proposal goes on the lines of what we discussed last week at the udig meeting
asantiago [n=asantiag@89.131.54.194] entered the room.
groldan: and the idea is to enable the smooth integration of geoapi Feature/Type into geotools trunk
jgarnett: gabriel can we have a breakout on this one; Justin also has some proposal he is writing up on a related complaint.
jgarnett: http://udig.refractions.net/confluence/display/UDIG/2008/01/24
groldan: driving needs being having to start dealing with WFS instances already serving complex featues
groldan: sure, that would be great
mgrant [n=mgrant@norbu.plus.com] entered the room.
jgarnett: it is just that it will be hard to handle this topic in the IRC meeting without that proposal page.
groldan: but at least I'd like to get from this meeting a sense of what people think
jgarnett: one question; what is your timeline on this one?
groldan: the usual, asap
jgarnett: I am still playing catch up on the getInfo proposal (also done for your timeline).
aaime: From where I stand I would prefer to have DataStore and co use Feature and FeatureType instead of simple, and let subclasses restrict the return values instead
groldan: this one includes the getInfo proposal I guess?
aaime: but I admit I haven't tought much about it
jgarnett: Eclsia gave me a good review of the work thus far; so I will finish up the getInfo work
simboss: are you planning on doing some work for coveages?
pramsey left the room (quit: Read error: 104 (Connection reset by peer)).
jgarnett: nope getInfo is already been and gone; the work is happening (but could use your help!)
aaime: jgarnett, did we vote the proposal?
pramsey [n=pramsey@mail.refractions.net] entered the room.
simboss: sorry, this question is related to the proposal page above
jgarnett: I am not planning any work for coverages; there is a proposal page there based on WCS; but until the coverage guys want to play I would like to live it out of this.
jgarnett: simboss the page has not been renamed yet.
jgarnett: gabriel can I rename that page now?
groldan: go ahead
aaime: yes, it was voted, ok
groldan: andrea having the current DataStore work on Feature/Type instead of Simple would just break too much code (all geotools data code) afaik
jgarnett: andrea; making use of FeatureType and Feature would be okay; but would break client code. Making a super class DataAcess and then making DataStore extend DataAccess seems a good compromise?
groldan: what I'm looking for is for a smooth integration
aaime: why, doesn't the counter variance work since we are on java5?
aaime: datastore clients will be broken, not datastores themselves
jgarnett: well I assume there is more client code; and it is more expensive to update.
groldan: that's it. Being a library we should care about clients
groldan: imho
aaime: jgarnett, it means the client code will have to choose which path to work on?
groldan: there's another reason too
jgarnett: confused; andrea are we talking about the same approach?
aaime: yes
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Data+Access+super+class+for+DataStore
groldan: which is to allow the smooth upgrade of client code that only knows how to deal with simpleFEature
aaime: you will be forcing the client to decide wheter to use the simple interfaces or rewrite to the new ones?
jgarnett: ah
jgarnett: I will not be forcing the client code to do anything
jgarnett: there is no need to change unless you want to work with complex data.
groldan: breaking the current API that way does not ensures clients that if they are set up to work with simple features they get back only simple-feature capable datastores
aaime: moreover, this will mean we'll have both around for... a very long time, right?
groldan: the other way, they can switch to work over the more generic Feature once they're ready, and keep getting only simple-feature capable datastores in the while
mgrant left the room (quit: Excess Flood).
jgarnett: (andrea undestand that I like your idea; less classes at the end of the day is a good thing - the decision comes down to how nice we want to be. We found that SimpleFeature was worthwhile because we could offer additional methods; can DataStore offer additional methods because it is restricted to simple content?)
asantiago left the room.
jgarnett: andrea you are correct; we would have both around forever. An intentional design choice; designed to take advantage of the fact that DataStore is restricted to SimpleFeature.
aaime: I see the DataAccess thing still has the most ominous mistake in our current DataStore api
aaime: no distinction between read only and read write access
jgarnett: keep talking
groldan: isn't that handled at the FeatureSource/Store level?
aaime: but you cannot say you just want a FeatureSource
aaime: you may get a FeatureStore and pay the price for it
groldan: ie. for a given DataStore, some FeatureSoruces may be editable, others not. Think of db user priviledges
jgarnett: ah
groldan: ok, got your point
jgarnett: does not getView( ... ) cover this case ?
aaime: not only the price, but also the risk
jgarnett: I get your point; and am not convinced that getView is explicit enough. But it is an option available now.
aaime: there is nothing using getView, not even sure it works properly
jgarnett: it works; uDig uses it.
aaime: we're talking about the future, not about now
jgarnett: to great effect I may add.
jgarnett: fair enough.
jgarnett: okay sounds good; we should add a getFeatureStore( Name ) method.
aaime: what about getFeatureSource(name, flavour)
groldan: and isEditable(Name) for the sake
aaime: flavour -> source, store, locking
jgarnett: gak.
jgarnett: Remember we have getInfo()
jgarnett: getInfo( Name ) could have information describing what is available.
aaime: (btw, FeatureSource2 is a name asking for vengeance... can we use something else?)
jgarnett: your point is a good one andrea; is source / store / locking an open set?
groldan: sure we could, just don't know what
aaime: It hasn't been for a long time (open)
acuster: delicious
jgarnett: thinking ...
jgarnett: well this is why we should have an IRC breakout; lots of good feedback :-D
simboss: can I ask something feature-unrelated guys?
jgarnett: do you need an agenda topic; or is it related?
aaime: FeatureSource2 -> GeoApiFeatureSource? (longer, not very fond of it...)
simboss: or better coverage-dataaccess related
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/CoverageStore+based+on+WCS+Specification
jgarnett: basically do the same thing based on the WCS specification
desruisseaux: If it is coverage related, could it fit in item 5?
jgarnett: DataStore based on the WFS spec.
jgarnett: (page is a placeholder for when you have time simboss/martin)
aaime: desriusseaux++
simboss: desruisseaux+=1
simboss: 
desruisseaux: Can we move on item 4?
jgarnett: andrea; just one idea then we should arrange an IRC meeting: ComplexDataStore, ComplexFeatureSource, ComplexFeatureStore, ComplexFeatureLocking
jgarnett: geoapi Feature extends Complex attribute after all.
aaime: that sounds about right
jgarnett: okay gabriel is that enough to keep you happy?
aaime: I'd prefer having SimpleFeatureSource instead... but that would break backwards compatibility?
groldan: ok, to make clear what I think is the main concern of this proposal. Having two separate interfaces for simple/complex allows to being completelly backwards compatible and not force clients to switch to complex if not needed. And if needed, switching to the more generic complex interface still gives you all the simple based ones
aaime: I understand that
jgarnett: yeah; I like it gabriel. please write it up and send out an IRC breakout email when ready.
jgarnett: sweet!
jgarnett: 4) jaxb
jgarnett: martin this one is you.
groldan: ok, Wednesday anyone?
desruisseaux: Can we add annotation on metadata package (for now), referencing probably later?
jgarnett: gabriel can you make sure justin is around? it will be silly if he is not around.
desruisseaux: Given that it would not introduce any new dependencies
groldan: jgarnett: will do, thanks all
desruisseaux: On Java 5, annotations would be erased in a way similar to generic type erasure.
desruisseaux: On Java 6, jaxb is bundled in the JDK - so no dependency needed for compiling.
jgarnett: Martin did you understand the email I sent? we can of course add the annotations; my concern is that there is lots of different annotations that would be fun. Why jaxb get any preference?
desruisseaux: Because it is in the JDK
acuster: it's in the jdk
jgarnett: um that is not my point so I should try again.
acuster:
jgarnett: there are lots of different ways to use a java bean; annotations are a smooth way to teach a javabean how to intergrate with any framework.
jgarnett: if we do jaxb (or any framework) it gives preference.
jgarnett: I would rather tell a consistent story: the default implementation that ships with geotools is a plain java bean
jgarnett: implementors can subclass and do what they want etc...
aaime: jgarnett ++
desruisseaux: The goal is to avoid implementation duplication.
jgarnett: we can make additional plug-ins for jaxb; xstream, hiberante etc...
aaime: metadata is a core module, not a pluggable extension
acuster: so how do you go to/from xml?
desruisseaux: xstream and hibernate are not in the JDK.
jgarnett: I am interested in duplication here; making sure the core library is free of specific bindings.
jgarnett: JDK does not enter into it for me
acuster: why?
groldan: acuster: in a number of ways. For the csw I participated on we used gtxml bindings
aaime: I'm sorry to say this, but my approach is exactly the opposite: if it comes from Sun there's a good chance it's bad
jgarnett: the concept of binding the default java beans to a specific technology here is what is at issue.
jgarnett: but I will offer you a olive branch.
aaime: I usually try to stay away
acuster: sorry that's not a technological argument
desruisseaux: But the binding is not restricted to that technology.
acuster: it's on the order of 'if it comes from eclipse it's bad"
aaime: bundled in the jdk is neither
acuster: which is just a waste of time
aaime: ie is bundled in windows, does it make it good?
jgarnett: If you take the lbrary in a different direction; we need to document it as such; and I would like to see that the factory / plug-in system used and tested. So I am confident we are not screwing over other use cases.
desruisseaux: We ensured with prototypes that the annotation works without API changes.
desruisseaux: The beans continue to work with arbitrary GeoAPI interfaces
jgarnett: acuster; I admit my argument is abstract; not based on jaxb / eclipse / JDK.
jgarnett: It is based on the design we chose (factory + plug-in). I want to trust that.
***acuster was talking about aaime's "it it comes from sun"
acuster: if it
desruisseaux: But they are not exclusive
jgarnett: okay; sorry for the confusion.
desruisseaux: The goal is to avoid a very large amount of duplication
acuster: groldan, would annotations block gtxml?
groldan: nope
aaime: wait
desruisseaux: ~100 classes to duplicate if annotation must be applied on separated classes.
jgarnett: so martin if you want to seperate out the metadata beans; document them as supporting jaxb that is cool.
acuster: so annotations would block only 'some other annotation system that is as yet unnamed'?
aaime: they might if the jaxb dependecy propagates outside of metadata
desruisseaux: What do you means by "separate out the metadata beans"?
desruisseaux: Andrea, no!!!
desruisseaux: No jaxb dependency on Java 5!!
acuster: and could others subclass to use their own annotations?
desruisseaux: No new dependency on Java 6 since it is bundled in JDK.
jgarnett: martin I already work with a complete implementation of the metadata classes in a commercial context (EJB 3).
aaime: sorry, can you elaborate?
groldan: I'm totally ignorant of annotation internals, so this might sound idiot, but couldn't they have home-made/tech-agnostic annotations and generate the jaxb ones automatically with some sort of preprocessor or such?
groldan: so you don't have to maintain them class extensions?
jgarnett: the duplication already happens; I am worried that if any of that implementation extends the default implementation I am in trouble. Or at least not a good steward of the geotools codebase.
desruisseaux: I don't think that you will be in trouble because no jaxb annotation declare the @Inherited meta-annotation
acuster: jgarnett, you seem to have the richest arguments against the proposal, is there any chance you could write them up?
desruisseaux: Any subclass you may create will not inherit the annotations.
sfarber: aaime: I believe martin's comment about no jaxb dependency on java5 goes something like this:
sfarber: if (compiling with java5)
Unknown macro: {jgarnett}
else if (compiling with java6)
Unknown macro: {sfarber}
desruisseaux: Saul, yes if compiling with Java 5 annotations are stripped.
aaime: how?
sfarber: they're just special comments, righT?
aaime: no
desruisseaux: Declared with @Retention(RetentionPolicy.SOURCE)
acuster: and if users want another annotation system, can they subclass and use that?
aaime: they are languange level constructs
jgarnett: not quite saul; they are a new java syntax borrowed from C#.
jgarnett: at the same level as synchornized; volitile.
***sfarber shrugs half-liddedly
jgarnett: they are hints to any code that cares to use them.
acuster: so rather than Martin duplicating 100 classes, the person who really wants to do differently could do that work themselves
jgarnett: you can find the values using reflection.
sfarber: yeah, I like that description jgarnett
aaime: jgarnett could have used the same approach and stick ejb3 annotations there
jgarnett: now you got the hang of it acuster.
aaime: they are j2ee standard no?
jgarnett: I would like martin to seperate out his implementation as a jaxb implementation; and document it as such.
jgarnett: but make no assumptions in the geotools codebase.
acuster: why?
acuster: how does the assumption restrict other uses?
jgarnett: geotools would no longer ship a default naked java beans implementation. but that is fine martin is the guy doing the work and he has to follow his needs.
jgarnett: question guys
acuster: if we don't restrict others, our time is more valuable than that of some future user
desruisseaux: Geotools would be shipped with an implementation suited with what JDK is shipped it
jgarnett: is the difficulty here the work; or the duplication of code ...
aaime: anyways, I don't like the idea, but if no jaxb dependency ever comes out of the module (as a maven dependency) I'll be -0 on the vote
desruisseaux: No dependency will come out as a maven dependency
desruisseaux: I would like to elaborate more:
desruisseaux: My problem is the duplication of code, and also the intelligence in the class.
groldan: on the other hand, what's wrong with metadata coming with a default way of marshalling/unmarshalling xml? compare that with no-op
desruisseaux: Metadata are just container, they can easily be replaced by other classes generated by some jaxb-processor
desruisseaux: But the next logical step after metadata is referencing
jgarnett: gabriel unless the default way is exactly the ISO flavour of metadata then it is a waste of time.
desruisseaux: Those classes are much more complex and there is no way a processor could generate "intelligent enough" classes.
jgarnett: (ie this stuff comes from a spec with a known xml binding)
groldan: jgarnett++, desruisseaux is it 19139?
desruisseaux: Our goal is to generate exactly the ISO flabor of metadata, yes
desruisseaux: Yes it is ISO 19139
jgarnett: at best it woudl be a way to use xml blobs to serialize data into a database.
jgarnett: ah; so now we are talking!
desruisseaux: We are tying to provides a way to read and formats ISO 19139 out of the box
desruisseaux: in a way that user can ignore if they want.
groldan: don't know you, but I would have paid what you asked to have that a couple years ago...
jgarnett: out of a java6 box but still :-P
desruisseaux: Yes, out of java 6 box
jgarnett: okay so since we are on the same xml page here; can we go back to my "abstract" concern about he library as a whole?
desruisseaux: You means the neutrality aspect? (why jaxb rather than hibernate?)
jgarnett: A lot of the SLD work we do would be a perfect fit for EMF and justin's mad parser; it is a bit beyond what jaxb can handle (every).
jgarnett: That system depends on annotations
jgarnett: should I use those annotations in the "rendering" module?
jgarnett: or should I keep it as an implementation available via a plug-in.
desruisseaux: I'm in favor with annotations if 1) they are bundle in JDK and 2) as closely compliant to ISO as we can.
jgarnett: neutrality aspect = yes. Want to make sure that we respect the library / plug-in boundary.
acuster: that's a new, non standard dependency right? so not exactly the same situation. However, if it saves you time and makes you more productive...great.
jgarnett: So as a library; can we split out the library from the plug-in ?
jgarnett: move the implementation to plugin/metadata
groldan: I guess its too core?
jgarnett: and fold the factory finder / utiltiy methods into library/api or library/util or library/geotools
jgarnett: well only the factory finder stuff is core.
jgarnett: bundling the factory finder stuff and the default implementation is the issue.
groldan: doesn't referencing use metadata?
desruisseaux: Yes factory stuff should move to a library/util or something like that, but isn't it a different topic than annotations?
jgarnett: yep; but only depends on the factory finder; everything else should be interfaces.
jgarnett: it is a related topic for me; because it changes how I view the library fitting together.
jgarnett: (ie is the library factory finder + plain java bean default as a low priority). Or do we make our bed an lay down in it...
groldan: ok, since metadata impl is just about implementing geoapi interfaces, it makes sense to be plugin to me
desruisseaux: In its current state, referencing depends on hard-coded constants in metadata module.
jgarnett: treat ourselves with the same factory seperation as we do others.
jgarnett: martin do you mean things like Citations ?
desruisseaux: Yes
jgarnett: Is there a lot of that going on?
desruisseaux: Maybe 10. There is also a few classes that have some intelligence in it (more than just a container). For example GeographicBoundingBoxImpl.
groldan: and due to the lack of a factory for metadata that's a hard to break junction...
acuster: metadata has never stood as a full fledge module on its own
jgarnett: is there no factory for metadata at all? I thought there was something ...
desruisseaux: Being able to leverage those "more than just container" implementation is one of my rational behind annotations in metadata.
groldan: there's not afaik
jgarnett: okay; so martin - is now the time to do a factory?
desruisseaux: (I means leverage them from a XML unmarshaling)
groldan: factory + builder would feet better
groldan: I tried to make a factory but gave up on the amount of work
jgarnett: I am still have trouble with the last sentence about "more than just container" - what did you mean?
desruisseaux: They have method doing operations.
desruisseaux: Example. GeographicBoundingBox.contains(...).
jgarnett: is this the "freeze" stuff?
jgarnett: ah.
groldan: though "special purpose" factories could fit better (i.e. just for the stuff you care for a specific need)
desruisseaux: Metadata has few of thems, but this issue become much more bigger when we reach referencing.
desruisseaux: My itend was to annotate referencing after metadata.
jgarnett: one solution is a static final method for contains( GeomgraphicBoundingBox box, ... ) and then use that method as common implementation.
desruisseaux: My wish is to be able to marshal and unmarchal OGC compliant CRS objects.
desruisseaux: and being able to use them for real transformations.
jgarnett: acuster and I had a similar discussion about geometry factory last week.
desruisseaux: (coordinate transformations)
desruisseaux: There is no way we will recreate a new referencing module with jaxb-generated annotated classes.
jgarnett: okay your goals are good to understand; and I missed them earlier. We should be sure to write them down on a proposal page.
aaime: doesn't jaxb support any external means of configuration?
aaime: Hibernate for example supports both annotations and xml files
simboss: (xml files are a apin though )
desruisseaux: If jaxb is bundled in JDK, if we annotate them in a way to generate ISO-compliant XML, if it doesn't impact the API (still possible to use arbitrary interface) and if it doesn't exclude other usage of the beans, why object?
simboss: (pain)
jgarnett: pin can be pain if used right.
jgarnett: martin my difficulty was about library direction; wanting to make sure factory system was in place and used.
jgarnett: ie we need to allow people the freedom to use xstream and other implementations; apparently a metadatafactory should be defined. I was hoping it was there for you to use ...
groldan: no factory system could save you from the lack of factories 
jgarnett: I also want to have a good answer for the EMF case.
desruisseaux: The EMF case?
acuster: jgarnett, this would block the emf case?
groldan: martin, does the idea of moving metadataimpl as plugin seem too unrealistic?
aaime: groldan, it's not about realistic, it's that is more work for them
aaime: (a very understandable and shareable point of view if you ask me)
jgarnett: EMF as the worst case example of a dependency that requires annotation intergration; that is so useful I cannot avoid it; but so scary that andrea will kill me if it creaps out of the plug-in system.
groldan: yup, all concerns raised here seem like more work for them though. I'm all up to make it easy for them though
jgarnett: martin can you do your jaxb thing and we start to slowly work on a metadata factory? With the goal of getting our story straight for GeoTools 3.
desruisseaux: It would be some work because of the hard-coded constants and additional methods. But given that referencing needs some kind of metadata implementation, if there is no other implementation around we would still have a dependency to this metadata module.
jgarnett: I don't mind sharing the work around; if it has a benifit to the library.
jgarnett: woudl that be a <test> dependency ?
desruisseaux: No, a runtime dependency
jgarnett: a runtime dependency to get at the common Citations I bet?
groldan: I for one the hardest problem I found with metadata is the definition of the equals method, which might be some work if you want to break the coupling for the constants
jgarnett: as long as the default factory was a low priority I think we would be in the clear.
jgarnett: equals implementation stuff is already defined as a static method; and you are correct gabrile that it is hard.
desruisseaux: Implementations needed are: Citation, Identifier, ResponsibleParty, GeographicBoundingBox, PositionalAccuracy (just the first one that popup from my head)
groldan: and in my case they had to be mutable, so equals needs to be defined in terms of what the spec says is mandatory
jgarnett: martin could we hard code those puppies; or would that break your serialization.
jgarnett: also how is jaxb serialization going to work when you have mixed implemntations
jgarnett: referenced envelope for example is geographic bounding box that is used lots of places right?
groldan: or rather make Citations an interface with getters and obtain the current one through the factory system from the plugin so you keep alltogether
jgarnett: (to answer my own question: the factory should have some copy methods; used to punt data into a known format so you can serialize)
desruisseaux: I don't remember for referenced envelope (would need to check). For serialization: wen mixed implementation, if not one of our metadata implementation, an adapter creates a temporary instance just the time needed for serialization.
jgarnett: good good.
desruisseaux: So yes we are doing exactly what you said just the line before.
jgarnett: martin I have a technical debt page for things about our library that suck; or were too expensive in time/communication/money for when deadlines were around.
aaime: Just for the sake of completeness
jgarnett: sounds like metadata factory should be added to the list.
aaime: the xml-xsd module would allow for creating separate serialization/parsing modules for both metadata and referencing
aaime: but I cannot say using it it's painfless
desruisseaux: They are not exclusive
aaime: no, but it would avoid adding the n-th xml tehcnology in the gt2 mix
desruisseaux: They idea is to provides a way for users to use jaxb out of the box if they wish. But everyone can use whatever other technology they wish (xstream, xml-xsd...)
groldan: indeed, I would rather like to be able of mixing serialization stuff from your default implementation for metadata and our gtxml one for Feature
aaime: mix as in using in the same serialization session? unlikely?
jgarnett: how expensive (compared to jaxb annotations) is making xml bindings?
desruisseaux: About adding n-th xml technology: I agree, but this technology is in the jdk... Not like an other project added in the mix
jgarnett: sax is in the jdk too
aaime: so what, all of the others came before?
desruisseaux: But not everyone have the other. Everyone with java 6 have jaxb.
jgarnett: note there are several jdk level java bean binding things around. some available in java 5
aaime: groldan, if we'll ever need to mix xml-xsd and jaxb stuff I guess we'll end up rewriting Martin work solid
desruisseaux: about sax being in jdk too: I would not be surprised in sax is used under the hood by jaxb, this is just a guess.
jgarnett: oh it is
groldan: could be, just when the time comes I would like to not having to reinvent the wheel
aaime: we'll be forced to
jgarnett: martin is there other jaxb tools you are trying to intergrate with?
aaime: unless justin can invent some funny kind of bridge between the jaxb annotations and the xml-xsd bindings (which may be possible)
acuster: but wouldn't you have exactly the same amount of work today?
groldan: aaime: I wouldn't bet against that possibility
aaime: acuster, wasn't working togheter in a library based on the assumption that we could reuse each other's work?
aaime:
jgarnett: (opps I have been so caught up I have forgot to run the meeting - bad jody.)
aaime: Anyways, I understand your position
acuster: sure, you can re-use martin's work, or, if it doesn't work for you, roll your own
jgarnett: I would write up the proposal; expect a lot of +0. And place the metadata factory stuff as technical debt.
desruisseaux: So does the conclusion is to write a wiki page, enumerate the pro and cons and revisit at next IRC?
acuster: right now we have nothing; having something that doesn't block other alternatives doesn't seem worse
jgarnett: nope; write the wiki page; start work (because we don't want to slow you down). and be prepaired to talk to me about a factory before geotools 3 goes out 
aaime: I disagree, but I don't intend to go on with this pointless discussion
aaime: my vote for this is and remains -0
desruisseaux: Okay I will write a wiki page tomorrow then.
groldan: mine is a community +1
jgarnett: I cannot slow you down for not using a factory that does not exist; I may go and bug the geoapi project about the lack of a MetadataFactory (perhaps you know some people there).
jgarnett: and thanks for the discussion.
jgarnett: 5) coverage evolution
acuster: can we punt that?
desruisseaux: I have to leave...
groldan: about the factory, as well as in the setters, I know Martin's intention is to keep things minimal until they're needed, so this might well be the time
jgarnett: I am learning a lot from the discussion; but mostly I am interested in seeing a way forward that does not involve branches/forks/confusion.
jgarnett: yeah we can punt on that; sorry for letting the last topic go long.
desruisseaux: Gabriel yes, if the need for a MetadataFactory arise now it may be time to think about it. But we will need a little bit of time...
jgarnett: groldan++ you are right.
jgarnett: well I can post the logs...
jgarnett: remember to send me contact info for committers if you have anything.
Labels