I think it's possible to specify/extend interfaces on the generated CT* classes. So the un-/marshaller would pick a version implementation and hopefully there is a common subset in the properties. I thought about lazy loading the fragments and only unmarshall them when needed. Maybe we could also provide a read-only android/tika implementation which doesn't need jaxb. This is all just an idea which I wanted to prototype to see if it's feasible ...
On 10/22/17 7:30 PM, Javen O'Neal wrote: > If the schemas aren't backwards compatible and we have CT* classes in the > XSSF classes, then wouldn't that mean that we'd need to dynamically import > the CT classes and reload the XSSF classes with the correct schema at > runtime? > > This sounds tricky. > > On Oct 22, 2017 02:30, "Andreas Beeker" <[email protected]> wrote: > >> Hi *, >> >> I'm struggling with jaxb and the ecma v5 schemas for quite a while - maybe >> you could have a look at [1]. >> >> My idea is to have several ecma version available in parallel and decide >> which to use after some >> introspection of a given ooxml file - AFAIK the versions are not downward >> compatible. >> Additionally my goal is to have the internal model saved as >> (serializable?) dom fragments >> or even strings, so you could use some kind of mmap list to handle big >> files. >> For reading the data you wouldn't need a schema, but for writing (and >> respecting the element order) I think there's >> no feasible method apart of xml binding, which would be applied on the fly >> on changed elements. >> >> So feel free to also suggest a different approach not only for the jaxb >> problem. >> >> Andi >> >> >> [1] https://stackoverflow.com/q/46869482 >> >> >>
signature.asc
Description: OpenPGP digital signature
