Problem with polymorphic serialization, inclusion type of `As.WRAPPER_OBJECT`, extra tag

[cowtowncoder]

(note: moved from FasterXML/jackson-module-jaxb-annotations#51 -- see that one for more context)

It looks like serialization includes an additional XML element level which should not be there.
As per original issue, for class like:

@XmlRootElement(name = "company")
@XmlAccessorType(XmlAccessType.FIELD)
public class Company {

  @XmlElements({
      @XmlElement(type = DesktopComputer.class, name = "desktop"),
      @XmlElement(type = LaptopComputer.class, name = "laptop")
  })
  private List computers;
  ...
}

produces XML output like

<company><computers>
    <computers>
      <desktop id="computer-1">
        <location>Bangkok</location>
      </desktop>
    </computers>
    <computers>
      <desktop id="computer-2">
        <location>Pattaya</location>
      </desktop>
    </computers>
    <computers>
      <laptop id="computer-3">
        <vendor>Apple</vendor>
      </laptop>
    </computers>
  </computers>
</company>

instead of more optimal way that JAXB serialization works:

<company>
    <computers>
        <desktop id="computer-1">
            <location>Bangkok</location>
        </desktop>
        <desktop id="computer-2">
            <location>Pattaya</location>
        </desktop>
        <laptop id="computer-3">
            <vendor>Apple</vendor>
        </laptop>
    </computers>
</company>

[cowtowncoder]

Additional note: suppression of List wrappers (difference between Jackson, JAXB -- Jackson defaults to using wrapper, JAXB not using) changes output, but not to optimal one: list wrapper goes away, but per-element wrapping remains.

[cowtowncoder]

Ok, yes, I can reproduce that. It is the currently intended behavior and does actually reflect same structure as JSON one; but due to discrepancy between structures (Object in JSON are not indicated by name, since there are no elements/tags) they are expressed as what is not optimal for XML.

I agree in that it would be nice to have more compact representation, similar to JAXB, where property name element would be replaced by type id, instead of both being present. But there are 2 main challenges:

1.Databind is format-agnostic (that is, can not have explicit handling for different formats), so there needs to be something in xml format module to translate the output appropriately
2. Change is backwards-compatibility breaking for existing Jackson usage; it may or may not be significant problem, but could be nasty if endpoints used different versions.

So, first things first: if change may be done (problem (1)), we could introduce a configuration setting to allow choosing behavior.

As to how to implement this, XML format could indicate it has "native" type ids, and if so, would get different call sequence that it could translate appropriately. This is needed to have contextual knowledge of what is type id; otherwise calls are justs "write START_OBJECT" and "write FIELD_NAME", without indication for semantic type of token. With native type ids, there are distinct calls.

Due to complexity of the approach, this will not be implemented for 2.7, but if there is time could perhaps worked on for 2.8.

[cowtowncoder]

Looks like we got a "collateral fix" here; will be fixed for 2.7.4.