Page 1 of 1

content in conref causing PDF build failure

Posted: Fri Feb 17, 2012 12:38 am
by leighw
My apologies if this is obvious. I've not been able to find a reference to it anywhere.

Oxygen 13.1 is exhibiting behavior that is causing some issues with conrefs, so my first question is whether this behavior is something I can configure. For example, when I insert a conref to a <dl>, Oxygen adds child elements, as below:

<dl conref="dl_source.xml#c_20120210124303349/a12345678">
<dlentry>
<dt/>
<dd/>
</dlentry>
</dl>

I only see this with Oxygen (and I see it with other elements, such as <table>, as well). Other XML editors consider this to be sufficient:

<dl conref="dl_source.xml#c_20120210124303349/a12345678"/>

If I can configure Oxygen not to require these child elements, then my problem is solved. In case it is not configurable, here is the problem it is causing.

These child elements are creating an issue with PDF builds (OT 1.5.4) when any child elements of the <dl> I am conref'ing have @id values. I get the "An attribute node (id) cannot be created after the children of the containing element" error.

When I comment the "extra" elements out:

<dl conref="dl_source.xml#c_20120210124303349/a12345678">
<!--<dlentry>
<dt/>
<dd/>
</dlentry>-->
</dl>

and run a PDF build, the build is successful. On the other hand, when I leave the "extra" elements in but remove any @id values on any of the children of the source <dl>, the build is again successful.

So clearly, the issue is that the conref has its own content (which it should not have) and that's conflicting with the dynamic creation of the content based on the conref source. Please tell me this is a user-configuration issue :-)

Thanks,
Leigh

Re: content in conref causing PDF build failure

Posted: Fri Feb 17, 2012 10:24 am
by Radu
Hi Leigh,

Elements which make a @conref also need to have valid content in the context of the current topic.
So the <dl> needs to have a <dlentry> child in order for the edited topic to be valid according to the DITA DTDs.
The fact that Oxygen adds the required child elements to them is important in order to achieve this.
So there is no setting controlling this behavior because this is the right way for an editor to behave.

The problem you are experimenting:
"An attribute node (id) cannot be created after the children of the containing element"
seems to be a bug in one of the stylesheets. Did you make any customizations to the DITA OT 1.5.4 that you are using?

I tried creating a small test sample which looked like this:

dl_source.xml

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="c_20120210124303349">
<title>Topic title</title>
<body>
<p>Topic paragraph<dl id="a12345678">
<dlentry id="e1">
<dt>DT</dt>
<dd>DD</dd>
</dlentry>
<dlentry>
<dt>DT2</dt>
<dd>DD2</dd>
</dlentry>
</dl></p>
</body>
</topic>
test.xml

Code: Select all

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "http://docs.oasis-open.org/dita/v1.1/OS/dtd/topic.dtd">
<topic id="test">
<title>test</title>
<body>
<p> <dl conref="dl_source.xml#c_20120210124303349/a12345678">
<dlentry>
<dt/>
<dd/>
</dlentry>
</dl></p>
</body>
</topic>
but could not reproduce the problem using Oxygen 13.2 (which comes bundled with DITA OT 1.5.4).

If you are using Oxygen 13.1 with DITA OT 1.5.4 this means that you probably edited the transformation scenario and set the "dita.dir" to point to the customized DITA OT 1.5.4 location.
You should edit again the transformation scenario, switch to the "Advanced" tab and click the "Libraries" button.
Then you should uncheck the checkbox "Allow oxygen..." and in that libraries list you should replace the library references which start with:

${frameworks}/dita/DITA-OT/...

with similar references to the DITA OT 1.5.4 libraries (you can remove the "dost-patches.jar" entry completely). The fact that you might have use the Java libraries of one DITA OT with the stylesheets from DITA OT 1.5.4 might be the cause for this problem.

Regards,
Radu