[oXygen-user] FM/OXY: Different DITA code for "conkeyref"

[Oxygen XML Editor Support (Radu Coravu)]

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.dissinger at 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 at oxygenxml.com
> https://www.oxygenxml.com/mailman/listinfo/oxygen-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.oxygenxml.com/pipermail/oxygen-user/attachments/20230127/8ed46517/attachment.htm>