On Nov 30, 2009, at 11:27 AM, Tatu Saloranta wrote:
> 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.
I don't know. What is the standard conversion from JSON to XML? What happens when there are annotations in the XML Schema that defines the instance?
I assume we are talking about using the Jackson streaming api and some kind of ContentHandler for the XML.
Let's say we should expect a GET request to a resource should return the content in at least xml and json. The exact same xml representation should be provided to the transformation. Would using Jackson's streaming api ensure that? Should the ContentHandler handle it?
What would happen to this:
{
content: "<p>blah blah</p>"
}
? Should we have some way to indicate that the content property should be emitted as CDATA or as markup?
>
>> 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!")
No. I see no need for round tripping. JSON is easier and quicker to send from the client than XML.
But there would be nothing stopping a transform from producing JSON (or *any* kind of plain text, e.g. JavaScript).
>
> ..
>>> 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.
Exactly. XSL will be much more important in the enterprise (well, publishing/document heavy) world when XSL has the ability to run natively on an XML DB (which is moving along...).
best,
-Rob
>
> -+ Tatu +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>