Hi Yaniv,
The fact that you described the XMLBeans proxy objects as "leaking" through the API says it all - they should have been encapsulated from the start.
The problem with the ooxml schema(s) is, that it is quite huge - and actually there are now at least 4 (ECMA) versions available. Similar to the binary format, one of the benefits of POI is, that you can modify the documents without destroying not supported elements.
If we hypothetical switch to a different marshaller it should preserve the infoset - I've never really tried JAXB (my colleague working with complex bipro schemas hates it ...), but that should be possible [1] So the next decision is, which mechanism should one pick, to not wrap/duplicate everything, which the ooxml schema provides. Up till now, I can only think of two options. Either we provide a strong typed (e.g. pojo based) interface - similar to the xmlbeans solution, or it would be some kind of flexible DOM, which is more prone for user errors. Btw. maybe it was just a act from necessity, but I like the solution of not providing the whole schema as classes (i.e. the reduced jar) - not sure if this is also possible with jaxb.
The best way to do that in light of its existing exposure is to deprecate it and provide a new alternative wrapper that will eventually supersede it.
Next part: would it be better to either duplicate (all) the classes for the new library or to switch inside the current classes depending on the config/input. The second approach would probably lead to an implementation which encapsulate the library specifics a bit more, so in case we decide another time to switch, it might not be so hard anymore ... (yeah, I know, totally hypothetical ... )
- the XMLBeans project is dead (in the attic for over a year, reboot is stuck)
there was a time some years ago, when I thought the same thing about POI ...
The conclusion that it should be replaced at some point
Yes, I agree with you totally ... maybe ;)
but for the shorter term be hidden and only used as an internal implementation.
Same as the top comment - I don't think we should wrap everything with POI classes, but let the user interfere with the "model", whatever that would look like. As a POI user I never really understood, why certain features were made final or protected in the api - and I needed to workaround them by either classloading or reflection tricks. Of course now as a committer things look a bit different, as you don't want to justify for all the handy helper methods and rather make them non-public. Best wishes, Andi [1] http://blog.bdoughan.com/2010/09/jaxb-xml-infoset-preservation.html --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
