RE: [docbook] Java binding (JAXB) for docbook.rng and docbook.xsd

Hello Wolfgang,

Thanks for your help.

1) I suppose I can then edit the docbook_fix.xsd and replace xs:NMTOKEN with appropriate data types.

2) As for the other problem I encountered with the relax NG schema, I suspect that even though xjc complains about the *name* of the class, it is really the *structure* of the definition that can’t be handled because, apparently, JAXB can’t create an enum class. E.g.,

[ERROR] Invalid class name "db.othercredit.class.enumeration". Either XJC has failed to derive a class name from XML name, or invalid name is given. Use <jaxb:class> customization to override a name.

line 4633 of file:/C:/Users/stefano/core/___docbookjava/jaxb/docbook.rng

is caused by:

<value>copyeditor</value>

<a:documentation>A copy editor</a:documentation>

<value>graphicdesigner</value>

<a:documentation>A graphic designer</a:documentation>

<value>other</value>

<a:documentation>Some other contributor</a:documentation>

<value>productioneditor</value>

<a:documentation>A production editor</a:documentation>

<value>technicaleditor</value>

<a:documentation>A technical editor</a:documentation>

<value>translator</value>

<a:documentation>A translator</a:documentation>

</choice>

</define>

If it so, it won’t be possible to bind docbook unless JAXB is somehow patched to deal with enum datatypes…

3) The reason I got into this is that I need to create some reports automatically from Java.

A few days ago I ran into the docbook format and I thought I’d use that to create my reports.

Your question actually made me go back to google and I did find other tools (e.g. JasperReport) which are probably more suitable than JAXB + docbook !!

- SC

From: Wolfgang Laun [mailto:wolfgang.laun@gmail.com]
Sent: Thursday, February 04, 2010 12:34 PM
To: stefano casadei
Subject: Re: [docbook] Java binding (JAXB) for docbook.rng and docbook.xsd (Are "role" and "type" duplicated in the 5.0 XML schema?)

Hi Stefano,

I've done a few quick fixes (occasionally just commenting things out), and now xjc
compiles. See the attached .xsd files.

The result is far from satisfactory. For one thing, many schema data types are
missing or wrong. Below is a list of all attributes with such types xsd:*, taken
from docbook.rnc. Some are OK in the .xsd (the IDREF's, for instance), but
fileref doesn't have any type set, which makes it xs:string (not a big deal, since
anyURI will be mapped to java.lang.String anyway.) But look at this:
<xs:attribute name="startinglinenumber" type="xs:NMTOKEN"/>
which should actually be xs:integer (or xs:int).

attribute endterm { xsd:IDREF }
attribute linkend { xsd:IDREF }
attribute linkends { xsd:IDREFS }
   attribute fileref { xsd:anyURI }
     attribute entityref { xsd:ENTITY })
attribute startinglinenumber { xsd:integer }
attribute width { xsd:nonNegativeInteger }
attribute scale { xsd:positiveInteger }
attribute otherclass { xsd:NMTOKEN }
    attribute scheme { xsd:NMTOKEN }
    attribute otherrenderas { xsd:NMTOKEN }
    attribute label { xsd:NMTOKEN }
    attribute mark { xsd:NMTOKEN }
    attribute startingnumber { xsd:integer }
    attribute override { xsd:NMTOKEN }
    attribute columns { xsd:integer }
    attribute othertype { xsd:NMTOKEN }
    attribute otherspatial { xsd:NMTOKEN }
    attribute othertemporal { xsd:NMTOKEN }
    attribute otherclass { xsd:NMTOKEN }
    attribute targetdoc { xsd:anyURI }
    attribute otherterm { xsd:IDREF }
    attribute otherterm { xsd:IDREF }
    attribute units { xsd:token }
    attribute begin { xsd:token }
    attribute end { xsd:token }
attribute zone { xsd:IDREFS }
    attribute startref { xsd:IDREF }
attribute otherunits { xsd:NMTOKEN }
    attribute arearefs { xsd:IDREFS }
    attribute linkends { xsd:IDREFS }
    attribute def { xsd:anyURI }
    attribute cols { xsd:positiveInteger }
    attribute colnum { xsd:positiveInteger }
    attribute morerows { xsd:integer }
    attribute cols { xsd:positiveInteger }
    attribute border { xsd:nonNegativeInteger }?
    attribute rowspan { xsd:nonNegativeInteger }?
    attribute colspan { xsd:nonNegativeInteger }?
      attribute span { xsd:nonNegativeInteger }?
      attribute span { xsd:nonNegativeInteger }?
    attribute namespace { xsd:anyURI }

All enumerations aren't made enum's, since they aren't defined as types, just inline. This
could be fixed with another customization.

Processing will be difficult.

May I ask why you want to create Java code from this XML schema? Perhaps
there is a better solution to your problem than using JAXB and Java?

-W

On Wed, Feb 3, 2010 at 9:43 PM, stefano casadei <scasadei@yahoo.com> wrote:

>> A fix wouldn't be so much work - write a simple script to extract the line numbers
>> from the error messages and then delete the lines. Let me know if you need
>> some help on this.

Some help would be great, I am not familiar with scripting languages.

I am attaching here a log file.

Actually it seems that compiling complex schemas is not trivial.

The Open Geospatial Consortium, Inc has created a JAXB subproject for their schemas:

https://ogc.dev.java.net/

Perhaps the same should be done for docbook to avoid duplication of work in the future.

-SC

From: Wolfgang Laun [mailto:wolfgang.laun@gmail.com]
Sent: Wednesday, February 03, 2010 6:34 PM
To: stefano casadei
Subject: Re: [docbook] Java binding (JAXB) for docbook.rng and docbook.xsd (Are "role" and "type" duplicated in the 5.0 XML schema?)

On Wed, Feb 3, 2010 at 5:47 PM, stefano casadei <scasadei@yahoo.com> wrote:

I don't really know if omitting those elements is safe (until 1 week ago I
knew nothing about xml).
Moreover, since there are a lot of errors of that kind I suspect it won't be
a quick fix...

I guess the docbook experts will have to confirm this.

A fix wouldn't be so much work - write a simple script to extract the line numbers
from the error messages and then delete the lines. Let me know if you need
some help on this.

On the other hand, the relax NG version, docbook.rng, PASSED the "parse
stage" of xjc:
parsing a schema...
compiling a schema...
But, I got lots of errors of the type:
[ERROR] Invalid class name "db.bridgehead.renderas.enumeration".
Either XJC has failed to derive a class name from XML name, or invalid name
is given.
Use <jaxb:class> customization to override a name.

These errors show up if and only if the string "enumeration" appears in the
name.
I tried to replace "enumeration" with "jenumeration" but that did not solve
the problem.
I am quite puzzled by this, even more so that the reserved keyword "class"
did not trigger an error
(e.g., <define name="db.biblio.class.attribute"> was ok).

I'll look into this, but using the XML schema is usually preferred.

-W

docbook message