Add support for data mapping (serialize/deserialize) of DOM trees (Node, Element)

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.4
  • Component/s: None
  • Labels:
    None

Description

(suggested by Scott D on Jackson dev list)

In addition to handling core JDK types and beans, it would be useful to be able to deserialize to/from DOM trees. This could be done by adding JsonSerializer/JsonDeserializer implementations for classes in "org.w3c.dom" package.
(sidenote: as an added bonus DOM interfaces are also part of Android SDK)

This seems like a nice way to allow some conversions between Json and Xml. However: one question is whether we should use one of existing "standard" conventions between xml and json.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tatu Saloranta added a comment -

Looking at Badgerfish convention, one problem is that it doesn't seem to support preserving processing instructions or comments. That may not be a huge problem, but does add round-trip losses.

Show
Tatu Saloranta added a comment - Looking at Badgerfish convention, one problem is that it doesn't seem to support preserving processing instructions or comments. That may not be a huge problem, but does add round-trip losses.
Hide
Permalink
Tatu Saloranta added a comment -

One more idea: given that Json has multiple datatypes, we can actually support dynamic detection of at least couple of different types.

For example: it seems reasonable that VALUE_STRING (basic Json string value) can be assumed to be regular serialized textual xml content, which can be parsed using xml parser (it is of course Json-encoded within string, but that gets unescaped during json parsing, so resulting String is valid xml if it was written as such).
But Json Object and Json Array can have different handling; and BadgerFish would naturally fit in as a Json Object I think.

This does not solve serialization side, where we have to choose a default strategy; but I think that can be handled by having a config option. Default to use should probably be as regular string; and BadgerFish could be enabled by a simple call.

Show
Tatu Saloranta added a comment - One more idea: given that Json has multiple datatypes, we can actually support dynamic detection of at least couple of different types. For example: it seems reasonable that VALUE_STRING (basic Json string value) can be assumed to be regular serialized textual xml content, which can be parsed using xml parser (it is of course Json-encoded within string, but that gets unescaped during json parsing, so resulting String is valid xml if it was written as such). But Json Object and Json Array can have different handling; and BadgerFish would naturally fit in as a Json Object I think. This does not solve serialization side, where we have to choose a default strategy; but I think that can be handled by having a config option. Default to use should probably be as regular string; and BadgerFish could be enabled by a simple call.
Hide
Permalink
Tatu Saloranta added a comment -

One more thought: given that proper serialization of DOM (without adding non-JDK deps) requires DOM Level 3 which may not be available on all platforms we want to target (for example, Android... blah), it may be best to try to encapsulate such additional xml-related functionality into a separate jar. It can contain sub-classes of standard serializer/deserializer providers, dynamically loaded if platform does have necessary classes available.

Show
Tatu Saloranta added a comment - One more thought: given that proper serialization of DOM (without adding non-JDK deps) requires DOM Level 3 which may not be available on all platforms we want to target (for example, Android... blah), it may be best to try to encapsulate such additional xml-related functionality into a separate jar. It can contain sub-classes of standard serializer/deserializer providers, dynamically loaded if platform does have necessary classes available.
Hide
Permalink
Tatu Saloranta added a comment -

Implemented, will be in 1.4.0.

Show
Tatu Saloranta added a comment - Implemented, will be in 1.4.0.
Hide
Permalink
Tatu Saloranta added a comment -

Included in 1.4.0 release.

Show
Tatu Saloranta added a comment - Included in 1.4.0 release.

People

  • Assignee:
    Tatu Saloranta
    Reporter:
    Tatu Saloranta
Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: