DITA 1.3 proposed feature #13090

Enhancements to the @style attribute in DITAVAL files.

Date and version information

Include the following information:

Original requirement

As stated on the 1.3 proposals wiki page:

"Consider changing the @style attribute in DITAVAL files to NMTOKENS instead of a DTD-specified list of choices. Document the minimum required supported styles (bold, italics, underline, double-underline, overline) but allow processors to support non-standard styles as well (e.g. smallcaps). This would allow <prop action="flag" att="otherprops" val="eyesonly" style="bold underline strike-through"/>"

Use cases

A user authoring a flag rule in a DITAVAL file wants to specify more than one type of styling for matched elements.

An industry-specific Open Toolkit plug-in needs to allow for custom highlighting using DITAVAL filtering.

A DITAVAL author wishes to mark certain content as obsolete by highlighting it with a line through the text.


DITAVAL authors will benefit by being able to specify more than one styling rule.

Tool vendors will benefit by being able to provide additional highlighting options for their customers, differentiating their offerings in the market. It will also allow for industry-specific highlighting options that might not be necessary to the broader DITA community.

This change is fully backwards-compatible with existing DITAVAL files. No conversion is necessary.


This proposal will require a minor change to the DITAVAL DTD and XML Schema, changing the type of the @style attribute from an enumerated list of values to NMTOKENS.

The only change required to the DITA specification is the description of the @style attribute in the Language Specification topic describing the <prop> element.

Vendors will need to modify their DITAVAL flagging processing to support more than one specified style. I would not expect this to be a major burden for most tools. This change should not significantly add to the percieved complexity of DITA.

Technical requirements

Processing feature
DITAVAL flagging will work the same as it always has, except that multiple style types can be applied, e.g. bold and italic. The list of values a processor must support will include:
  • The currently allowed @style values.
    • underline
    • double-underline
    • italics
    • overline
    • bold
  • In addition, the line-through token must also be supported.
  • A processor may provide additional token values supported by tools provided by that vendor. Such custom tokens should start with a vendor-specific prefix, e.g. myco-blink.
Topic or map specialization
No new specializations.
No new domains.
No new elements.
New definition and processing rules for the @style attribute on <prop> as described above.
Overall usability
Customers that author DITAVAL files using tools that provide a dropdown or pick list for NAMEGROUP attributes will lose those hints. Authoring tools may provide additional tools for specifying styling, alleviating this concern.


A user who wants to specify both bold and underlining for elements whose audience attribute contains the value "teacher" could add a DITAVAL prop such as the following:

<prop att="audience" val="teacher" action="flag" style="bold underline" />

A vendor of learning and training tools wishes to the ability render some content, such as that marked with audience="teacher", as invisible (foreground text color matches background color, requiring text selection to read) for certain outputs. They could provide the ability to flag such content for that processing by allowing a custom acme-invisible token for use in DITAVAL flagging.