I am hoping to attract some comments from other members of the community by gathering a few threads of debate between Sergey and myself in one place. If I misrepresent his side of these arguments I'm sure he'll let me know. I also plan to ask some questions on the user list.
[1] The default JSON provider. I've been comparing the Jackson JSON provider to the JSONProvider in CXF. I see three possibilities: [a] Deprecate ours in favor of theirs [b] Document the fact that Jackson works with CXF and write up the tradeoffs. [c] Do nothing. I would like to see us at least take door [b]. Our JSONProvider has some issues: it consists of a combination of JAXB and Jettison. The latter has bugs that keep coming up. The former poses issues for some users, or so I am told. Jackson has some advantages, I think. The most notable is an annotation model that is small and straightforward for JSON production and consumptin. [2] The role of data binding providers. I can see why users would find a lot of value in the data binding providers when their content type is XML. The existing data bindings are all in the XML business; their various controls and options are all relevant. Work users put into setting them up is largely relevant, it not always sufficient (e.g. @XmlRootElement requirements). However, I think that there are caveats that deserve discussion in our documentation. Marking a transient property to be ignore, that's good all around. A production schema, on the other hand, may well have XML constructs that are not friendly to some sort of simple Javascript client. When we get to JSON, however, I'm much more skeptical. Even without the various bugs encountered in Jettison, the JSON you get when you push a complex pile of XML into Jettison is pretty convoluted. I offer a sort of a reduction argument: if the interface is a simple one, then no one needs a complex data binding, and if it is a complex one, expecting to use what comes out of the data binding + Jettison is likely to run into trouble. I'm not proposing to delete any code here, just to set expectations. [3] The role of Aegis in all of this Aegis has turned into a central point in these issues for several reasons. First, we put effort into making Aegis work with JAX-RS, so that people who wanted to avoid JAXB had an alternative. Then we noticed that Aegis always produces 'qualified' schemas. Then we noticed that Jettison's model of namespace management doesn't work for this purpose. It requires a static mapping of namespaces to prefixes, rather than a dynamic mapping as in XML itself. So, my view is that we should push Jackson as a solution to a JAXB-less mapping from Java to and from JSON. The alternative would be to invent 'unqualified' Aegis. (a) I don't know if I have time, (b) I fear that it will only expose a next layer of things people don't like, like the extra layer of elements in Aegis maps. Sergey is unpersuaded. Anybody else care to toss an opinion into the right? If someone else wants to jump on an option to make Aegis unqualified, don't think for a moment that I'll protest.
