Enhancements to the @style attribute in DITAVAL files.
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. strikethrough, smallcaps). This would allow <prop action="flag" att="otherprops" val="eyesonly" style="bold underline strikethough"/>"
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.
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.
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.