--- 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. :-/
> 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.
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? ;-)
-+ Tatu +-