jaxb problems

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

jaxb problems

kiwiwings
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 (495 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jaxb problems

Javen O'Neal-2
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" <[hidden email]> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: jaxb problems

kiwiwings
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" [hidden email] 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 (495 bytes) Download Attachment