You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Jason Harrop <jh...@gmail.com> on 2008/04/09 14:02:00 UTC
ooxml branch and docx
Hi
By way of introduction, i'm the maintainer of docx4j, a library for
manipulating WordprocessingML files in Java, recently re-released
under the apache v2 license.
I was looking today at my generated classes for CT_RPr and CT_ParaRPr
- the content model for an rPr element inside a pPr is essentially the
same as for an rPr in a run element, except that it is top and tailed
with some change tracking stuff:
<xsd:complexType name="CT_ParaRPr">
<xsd:sequence>
<xsd:group ref="EG_ParaRPrTrackChanges" minOccurs="0"></xsd:group>
<xsd:group ref="EG_RPrBase" minOccurs="0"></xsd:group>
<xsd:element name="rPrChange" type="CT_ParaRPrChange" minOccurs="0">
:
I would have liked the generated class for ParaRPr to extend the class for RPr.
I generate my classes with JAXB, and - at least with its out of the
box settings - this doesn't happen.
So I thought I'd see what XMLBean generates. Answer: much the same.
I did notice something about some of the other classes generated by
XMLBean which i thought i should raise on this list.
org.openxmlformats.schemas.wordprocessingml.x2006.main.CTP and CTR. -
rather than a single list for the content (EG_PContent and
EG_RunInnerContent), there is a list or array per element.
Compare the paragraphContent field in
http://dev.plutext.org/trac/docx4j/browser/trunk/docx4j/src/main/java/org/docx4j/wml/P.java
and runContent element in
http://dev.plutext.org/trac/docx4j/browser/trunk/docx4j/src/main/java/org/docx4j/wml/R.java
generated using JAXB.
cheers,
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: ooxml branch and docx
Posted by Nick Burch <ni...@torchbox.com>.
On Thu, 10 Apr 2008, Rainer Schwarze wrote:
> > I noticed this too. It's rather pesky. Do you know if the schema instructs
> > one to extend the other, or are they independently defined with repeating
> > contents? (We'll want to know the answer before we go and ask xmlbeans
> > about supporting the java class hierachy)
>
> From what I can see with my limited schema knowledge, CT_RPr and
> CT_ParaRPr both (among one or two others as well) refer to EG_RPrBase
> within their <xsd:sequence> section. So it looks to me as if it is
> common contents.
I concur. I've done a post to the xmlbeans list to ask if we can get a
common interface or something for them
> > Yeah, this is a bit pesky. Might be worth a post to the xmlbeans list, to
> > ask if it's possible to get the list of all children
>
> My current solution is a helper class which uses XmlCursor to build the
> lists of all children (there's a sample named "Order Matters" (if I
> remember well) at the XmlBeans site - it is similar to that one). This
> works for now in my case.
Cool. I've done a post to the xmlbeans list, and I'll play with the
xmlcursor stuff if there's no nicer solution they can suggest
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: ooxml branch and docx
Posted by Rainer Schwarze <rs...@admadic.de>.
Nick Burch wrote:
> On Wed, 9 Apr 2008, Jason Harrop wrote:
>> I was looking today at my generated classes for CT_RPr and CT_ParaRPr
>> - the content model for an rPr element inside a pPr is essentially the
>> same as for an rPr in a run element, except that it is top and tailed
>> with some change tracking stuff:
>
> I noticed this too. It's rather pesky. Do you know if the schema instructs
> one to extend the other, or are they independently defined with repeating
> contents? (We'll want to know the answer before we go and ask xmlbeans
> about supporting the java class hierachy)
From what I can see with my limited schema knowledge, CT_RPr and
CT_ParaRPr both (among one or two others as well) refer to EG_RPrBase
within their <xsd:sequence> section. So it looks to me as if it is
common contents.
>> I did notice something about some of the other classes generated by
>> XMLBean which i thought i should raise on this list.
>>
>> org.openxmlformats.schemas.wordprocessingml.x2006.main.CTP and CTR. -
>> rather than a single list for the content (EG_PContent and
>> EG_RunInnerContent), there is a list or array per element.
>
> Yeah, this is a bit pesky. Might be worth a post to the xmlbeans list, to
> ask if it's possible to get the list of all children
My current solution is a helper class which uses XmlCursor to build the
lists of all children (there's a sample named "Order Matters" (if I
remember well) at the XmlBeans site - it is similar to that one). This
works for now in my case.
Best wishes,
Rainer
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: ooxml branch and docx
Posted by Nick Burch <ni...@torchbox.com>.
On Wed, 9 Apr 2008, Jason Harrop wrote:
> I was looking today at my generated classes for CT_RPr and CT_ParaRPr
> - the content model for an rPr element inside a pPr is essentially the
> same as for an rPr in a run element, except that it is top and tailed
> with some change tracking stuff:
I noticed this too. It's rather pesky. Do you know if the schema instructs
one to extend the other, or are they independently defined with repeating
contents? (We'll want to know the answer before we go and ask xmlbeans
about supporting the java class hierachy)
> I did notice something about some of the other classes generated by
> XMLBean which i thought i should raise on this list.
>
> org.openxmlformats.schemas.wordprocessingml.x2006.main.CTP and CTR. -
> rather than a single list for the content (EG_PContent and
> EG_RunInnerContent), there is a list or array per element.
Yeah, this is a bit pesky. Might be worth a post to the xmlbeans list, to
ask if it's possible to get the list of all children
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org