On Nov 30, 2009, at 3:19 AM, Tatu Saloranta wrote:
> On Sun, Nov 29, 2009 at 8:33 AM, Robert Koberg
> <rob.koberg_at_gmail.com> wrote:
>>
>> On Nov 27, 2009, at 11:46 PM, Tatu Saloranta wrote:
> ...
>>> So just pipe in stream into XSL processor, which will use whatever
>>> is
>>> fastest way (Saxon builds its own TinyTree, Xalan probably something
>>> similar).
>>
>> That makes sense. So, as you read the stream of JSON events you
>> emit the corresponding XML event. I remember discussing this a
>> while ago on the Jackson list. Is there anything in Jackson that
>> will make this process simple? :) Perhaps something like a
>> JSONSource (implements javax.xml.transform.Source)?
>
> 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 way around, but still will you require the result of any XSL
transformation to be mapped back to JSON?
> That's also why javax.xml.transform Source/Result is an edge case: it
> is named to suggest it's just for XML (not JSON). But functionality
> contained is fairly generic, mostly just input/output objects, and
> public/system id (which are generic references too). So I am not sure
> if JSONSource/Result would make sense or not.
>
> 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.
Paul.