On Feb 13, 2009, at 8:06 PM, Tatu Saloranta wrote:
> --- On Fri, 2/13/09, Paul Sandoz <Paul.Sandoz_at_Sun.COM> wrote:
>
>>> One quick question on "natural" JSON: is that "truly natural"
> ...
>> or a lighter-weight mapping to accomodate for xml bindings?
>>
>> I would say we have tried to achieve as much of the former
>> as possible within the context of the JAXB framework while
>> minimizing the constraints of the latter.
>
> Ok, makes sense. So: [more] natural, but not "native".
>
> ...
>> In general we are finding this to be a hard problem because
>> different developers have different requirements and
>> expectations. For example some what namespaces represented
>> in JSON, or a way to support substitution.
>
> Absolutely. It is a hairy problem.
> But even ignoring namespace aspect, problem is the impedance between
> information models: xml is hierarchic, json resembles object/struct
> model (not real object model because it lacks identity, but similar).
>
> So challenge is similar to matching sql/objects (hibernate), and
> general xml/objects (that jaxb does).
>
> Of course, it is only a problem if one has to directly convert
> between xml and json -- theoretically that wouldn't need to be a
> requirement.
> After all, you can bind xml to/from objects, as well as json to/from
> objects, So since internally services only see objects, separate
> serializations could work independently. And if for some reason such
> transformation is needed, it could be done in 2 steps, from one
> format to object, then from object to result data format.
>
> And this is where direct dependencies to JAXB really become a
> problem. :-/
>
Potentially there are some advantages. JAXB has some interesting ways
of extending the binding of data types. Character data as well as
structure can be validated. It should also be possible to support a
general filtering approach in an abstract fashion based on the StAX
API (a developer has added a patch to do just that).
>> In part i think we need to set clear expectations on when
>> to use which mapping, or when not to use JSON.
>
> Yes -- in many ways, json support is just for interoperability; it's
> not really a first-class citizen. Which is good enough for many use
> cases of course, just not as good as support for xml.
>
> It would be nice if there was something more data format agnostic
> for Jersey to use as integration point, that JAXB could implement;
> instead of having to rely directly on JAXB itself.
> That is, a more general object/data binding framework. For Jersey,
> needs should be quite simple -- external data as byte stream,
> convert to/from objects passed to services users define.
> Conceptually that is the case already; types accepted and returned
> are annotated, without need for directly referencing machinery that
> does conversions.
>
If i understand you correctly then we may have what you require: JAX-
RS message body readers/writers.
But may be for the case JAXB-related types it needs some finessing if
you want to plug in an alternative JSON-based convention that does not
go through the JAXB infrastructure but wants to use the same types
i.e. we would like to ensure that JSON plays nice with JAXB or not
depending on what convention you choose, in addition to the case when
those types are not associated with JAXB annotations but still require
support for JSON.
> At this point this is just wishful thinking; with 1.x release it's
> not possible to change core API depedencies. But maybe for 2.0? ;-)
>
:-) would you be interested in helping out?
Paul.