JAXBElement?

[holgerschlegel]

Is there any reason why some document elements are wrapped by an JAXBElement instance and others are not?
For example, the content list of the Body class may contain JAXBElement<Tbl> (instead of just Tbl) but directly containing P elements (instead of JAXBElement<P>).

And one other question: Is the docx4j library under active development process or will there be changes only if bugs are detected?

[jason]

Is there any reason why some document elements are wrapped by an JAXBElement instance and others are not?
For example, the content list of the Body class may contain JAXBElement<Tbl> (instead of just Tbl) but directly containing P elements (instead of JAXBElement<P>).

This is dictated by JAXB, more specifically, by the content of the XSD for WML.

I found (when compiling the xsd using xjc) that elements defined using the form <xsd:element @name=' ' @type=' '> (at least in a group) sometimes instantiated as the expected object, other times as a JAXBElement. This could be prevented in certain cases by redefining as < @ref= ..>

For example, the schema currently contains:

Code: Select all

   <xsd:group name="EG_ContentBlockContent">
      <xsd:choice>
                        :
         <xsd:element ref="p" minOccurs="0" maxOccurs="unbounded"/>

         <xsd:element name="tbl" type="CT_Tbl" minOccurs="0"
            maxOccurs="unbounded">



If this were replaced with:

Code: Select all

   <xsd:group name="EG_ContentBlockContent">
      <xsd:choice>
                        :
         <xsd:element ref="p" minOccurs="0" maxOccurs="unbounded"/>

         <xsd:element ref="tbl" minOccurs="0" maxOccurs="unbounded"/>



I expect you'd get back a org.docx4j.wml.Tbl, rather than a JAXBElement.

And one other question: Is the docx4j library under active development process or will there be changes only if bugs are detected?

Active, but not intensive. Pace of development reflects volume of contributions (by me and others). You are welcome to contribute