Hi Frank,

The content inside the dlentry which has a conref is fallback content, it's used only if the conref does not resolve. So what's there is not really important. But it also needs to be there to make the XML valid according to the DTDs.

Oxygen by default does not generate that extra paragraph inside the dd: "<dd><p/></dd>".

So this is probably something which you defined in your framework customization, maybe you specified in your "cc_config.xml" for example that when a "dd" is inserted, Oxygen should also insert a paragraph inside it.

About that Schematron rule, I would refine it to skip looking inside elements which contain conrefs:


<sch:rule context="dd[not(parent::*[@conref])]">

Regards,

Radu

Radu Coravu
Oxygen XML Editor


On 1/26/23 16:56, Frank Dissinger wrote:

Hi list,


As some of you know, I have just switched from FrameMaker to oXygen.


I discovered that the two programs create different DITA code for "<dlentry conkeyref="...">. oXygen creates an empty *<p/> *tag before the closing </dlentry> tag. Are both codes equally correct? Or is one better than the other?


oXygen code:

<dlentry conkeyref="lib_ref/search">
            <dt/>
<dd>*<p/>*</dd>
        </dlentry>

FrameMaker code:

      <dlentry conkeyref="lib_ref/search">
           <dt/>
<dd/>

</dlentry>

Referenced dita topic:

      <dlentry id="search">
        <dt><uicontrol keyref="color_search_box"/></dt>
        <dd><p>Use this option to quickly find a specific color if many colors are loaded.</p><p>Enter the first few           letters or any part of the color name. This will select the first color the name of which is matched by these           characters.</p><p>If your input matches multiple colors, click on the small arrow to select a color from the           list. This list contains only colors with names that contain the characters you have entered.</p></dd>
      </dlentry>


BTW: This difference became obvious after defining a Schematron rule which outputs an error for <dd> elements which do not have any child elements. I have defined this rule and many similar ones because I want to wrap every paragraph in <p> wherever <p> is valid. The FM-generated code (<dd/>) is marked up as invalid by this rule. It would be a nightmare to change all these hundreds of "conkeyref"s in all my projects. Or should I just do without this check (i.e. the second "assert")?


<sch:pattern id="Check_DD">
        <sch:rule context="dd">
            <sch:assert test="not(text()[normalize-space()])">DD element must not contain any text.</sch:assert>
<sch:assert test="*">DD does not contain any child elements</sch:assert>
        </sch:rule>
    </sch:pattern>


Regards,

Frank

--

*Frank Dissinger*

Documentation Manager

....................................................................

*CGS Publishing Technologies International GmbH*

*Email *frank.dissin...@cgs-oris.com | *Web* www.cgs-oris.com <http://www.cgs-oris.com/>

*Address* Kettelerstr. 24 | D-63512 Hainburg | Germany

*Phone* +49 6182 9626-27 | *Fax* +49 6182 9626-99

*Commercial register* Offenbach, HRB no. 21495

*Managing directors* Bernd Rückert, Christoph Thommessen


https://www.cgs-oris.com/Signatur.png <https://www.cgs-oris.com/signatur>

_______________________________________________
oXygen-user mailing list
oXygen-user@oxygenxml.com
https://www.oxygenxml.com/mailman/listinfo/oxygen-user
_______________________________________________
oXygen-user mailing list
oXygen-user@oxygenxml.com
https://www.oxygenxml.com/mailman/listinfo/oxygen-user

Reply via email to