users@jersey.java.net

Re: [Jersey] XSL transform annotation and message body reader/writer

From: Tatu Saloranta <tsaloranta_at_gmail.com>
Date: Mon, 30 Nov 2009 11:27:19 -0800

On Mon, Nov 30, 2009 at 12:31 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>...
>> Not yet, although there are Jira issues for possible things (like
>> exposing JSON content as trivially translated SAX events). But
>> generally Jackson focuses on 'pure' JSON aspects, so most XML features
>> are for minimal interoperability. So for XSL Jackson might not help a
>> lot. XSL is for XML.
>>
> I suspect mapping JSON to XML infoset is a lot easier to do than the other

Exactly, yes. I wouldn't want to tackle the other direction for this
exact reason; there are already mapping conventions that do this, no
need to rewrite those.
This is mostly off-topic for Jersey/Jax-rs anyway.

> way around, but still will you require the result of any XSL transformation to be mapped back to JSON?

Good question -- I would not expect that to be needed. Or, rather, if
that was expected, solution looks more like a problem than solution.
:-)
("if that's the answer, I don't even want to know the question!")

..
>> I would think that reusable XSL filter would be useful for others, at any
>> rate.
>
> From a Jersey perspective the application developer does not need to know
> how such a filter works i.e. the re-parsing/buffering is an implementation
> detail and perhaps for a first cut is not an issue and we could work on ways
> to make this more efficient while such a feature can be used and is useful
> for developers.

Sure: just configure filter with stylesheet, and it gets applied
during processing? That sounds like useful thing for many use cases.
And for others, well, writing your own functionality is not all that
hard if you need more control.

-+ Tatu +-