On Mon, Nov 30, 2009 at 12:00 PM, Robert Koberg <rob_at_koberg.com> wrote:
>
> On Nov 30, 2009, at 11:27 AM, Tatu Saloranta wrote:
...
>> 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?
Maybe we are thinking slightly different use cases?
My approach is usually not to convert between secondary data formats
(json to xml or vice versa), except when necessary to support legacy
systems. So in that sense I was not thinking of seamless conversions.
But that does not mean others might not want it. So I agree in that if
support for such conversions, as part of framework, are needed, yes
that would be within jax-rs realm.
> I assume we are talking about using the Jackson streaming api and some kind of ContentHandler for the XML.
Possibly? :-)
> Let's say we should expect a GET request to a resource should return the content in at least xml and json. The exact
As alternatives (either one or the other) or as combination (some
parts JSON, others XML)?
> same xml representation should be provided to the transformation. Would using Jackson's streaming api ensure that? Should the ContentHandler handle it?
For Jackson, I am not thinking of adding routing, so it would be
strictly doing whatever is requested: in case of JSON->XML, being
requested to send events to ContentHandler, based on either content
read via JSON parser, or being written using JSON generator.
ContentHandler in such case would not be aware of anything funny going on.
But it is probably easier to consider actual expected use cases to
know what makes sense.
...
>>> 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
>
> No. I see no need for round tripping. JSON is easier and quicker to send from the client than XML.
And there is also possible loss from conversions, so minimizing number
of conversions makes sense.
> But there would be nothing stopping a transform from producing JSON (or *any* kind of plain text, e.g. JavaScript).
Not technically, although XSL is often not very optimal choice for
producing non-XML/HTML output (except maybe for things like pdfs, via
extensions).
...
>>> 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...).
Yeah, Native XML DBs are interesting, and make lots more sense than
Oracle (et al) approach of storing BLOBs and adding bit of lipstick in
all the wrong places. :-)
Ditto for Native JSON DBs (CouchDB?). Not as general replacements, but
replacements in cases where advanced content-based queries make sense,
and flexible structure (the good old "right tool for the job"
disclaimer).
-+ Tatu +-