Topics

How to constrain standard DITA topic type? #constraints

Frank Ralf
 

Hello,

I have a constraint module (DTD-based) that sets the default value for the @placement attribute of the <image> tag to "break" instead of "inline" as the DITA standard does. I have integrated this constraint into my custom DITA topic types. But this constraint should also apply to standard DITA topics that are used together with my custom DITA topics. How can I apply the same constraint to standard DITA topics? Can I just copy the relevant topic type shells into the folder of my constraint module and integrate the constraint as described in http://dita4practitioners.github.io/dita-specialization-tutorials/body/part-config-and-extend/tutorials/constraint-module/constraint-domain-dtd-step-4.html?

Any pointers welcome.

Frank

ekimber@contrext.com
 

You would have to copy and modify the standard shells and/or change your catalog to point the OASIS-defined public IDs to your local shells for the corresponding topic types.

The whole point of local shells is that you control them...

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 2/18/20, 10:44 AM, "Frank Ralf" <main@dita-users.groups.io on behalf of @fralf> wrote:

Hello,

I have a constraint module <http://dita4practitioners.github.io/dita-specialization-tutorials/body/part-config-and-extend/tutorials/constraint-module/creating-constraint-module.html> (DTD-based) that sets the default value for the @placement attribute of the <image> tag to "break" instead of "inline" as the DITA standard does. I have integrated this constraint into my custom DITA topic types. But this constraint should also apply to standard DITA topics that are used together with my custom DITA topics. How can I apply the same constraint to standard DITA topics? Can I just copy the relevant topic type shells into the folder of my constraint module and integrate the constraint as described in http://dita4practitioners.github.io/dita-specialization-tutorials/body/part-config-and-extend/tutorials/constraint-module/constraint-domain-dtd-step-4.html?

Any pointers welcome.

Frank

Julio J Vazquez
 

The question really becomes, is the constraint required? If you have icons within your text, this constraint would break your formatting unless you compensate for it in your XSLT. If your writers are using best practices, images are not children of paragraphs, the constraint is unneeded. 

Julio J. Vazquez

Frank Ralf
 

Hi Eliot,

Many thanks for the quick reply and the pointer. Changing the catalog to point the OASIS-defined public IDs to my local shells was the missing link.

Best regards,
Frank

Frank Ralf
 

Hi Julio,

Thanks for your feedback. I agree with you in principle. However, the current use case is that images are only allowed within <fig> elements which makes them indeed children of another block element. "Naked" images like icons are currently not used. Therefore I think changing the default behavior for the display of images from "inline" to "block" is a valid solution.

And even if our customer is moving in the direction of using standard DITA instead of their customized DITA, we will have to keep this behavior because of the legacy DITA documentation that would break if we change the default behavior.

Kind regards,
Frank