Making @class attributes available to refactoring operations

[chrispitude]

When processing or validating DITA, it can be useful to access the @class attribute. For example, this template:

Code: Select all

<xsl:template match="addressdetails|administrativearea|b|codeph|coords|country|delim|em|equation-inline|equation-number|filepath|hwcontrol|i|lcAreaCoords|lcAreaCoords2|light-b|line-through|locality|localityname|menucascade|msgph|oper|organizationname|organizationnamedetails|overline|partno|ph|postalcode|repsep|sep|strong|sub|sup|synph|systemoutput|thoroughfare|tt|u|uicontrol|userinput|var">
    ...
</xsl:template>

could be rewritten as follows:

Code: Select all

<xsl:template match="*[contains-token(@class, 'topic/ph')]">
    ...
</xsl:template>

Plus, the second method automatically considers user specializations whereas the first method does not.

In Oxygen,

• Schematron checks see @class values.
  • This includes interactive editor checks and batch validation.
  • XSLT templates used inside the Schematron file also see @class values.
• XSLT refactoring operations do not see @class values.

Here is a testcase:

oxygen_include_class_in_refactoring.zip

(20.97 KiB) Downloaded 164 times

The testcase defines a Schematron check for specialized elements, and an interactive quick-fix that allows you to unspecialize an element. The quick-fix leaves lingering explicit @class attributes in the DITA source file, so I would need to update the code to fix that.

unspecialize.gif (58.2 KiB) Viewed 1230 times

The testcase also defines a refactoring operation that tries to unspecialize entire DITA topics. It does not work because there are no @class attributes made available in refactoring operations.

But, if @class attributes were made available in refactoring operations, then existing refactoring operations could break. For example, a template that copied @* into a new element would also copy the refactoring-added @class attribute.

Is there some clever way that @class could be accessed in refactoring operations without interfering with existing refactoring operations? For example, could refactoring operations populate the @class attribute values before the operation, apply the transformation, then clean them up after the operation? Or would this break some other theoretically possible workflow where @class attributes were explicitly present in the source file (or added!) and the user does not want them to be cleaned up?

Just thinking out loud for now, but I could see a lot of use for refactoring operations being more knowledgeable about specializations and specialization ancestry!

[Radu]

Hi Chris,

We have an internal issue for this and I added your feedback to it:

EXM-32599 [XML Refactor tool] - Default attributes should be visible when refactor documents

We do not have a good idea about how this could be implemented. We remove the schema reference and doctype declarations before passing the XML document to the XSLT processor, in this way the processor processes directly the XML content without it being enriched with default attributes. If those default attributes would appear, there would be no processing distinction between a document containing them inside the XML or inheriting them from the schema. They could also end up in the output if not explicitly filtered.
Maybe we could create some kind of pre-defined extension function XSLT function like "oxy:getDefaultValue(., "@class")" which could be used to match elements...

Regards,
Radu

[chrispitude]

Maybe instead of including @class attributes in refactoring operations by default, a refactoring operation's descriptor could "opt in" to ask for them? Then only refactoring operations that want them would get them.

I guess then the question would be, should Oxygen automatically strip out lingering @class attributes in the resulting files, or would this be the refactoring operation's responsibility?

[Radu]

Hi Chris,

I added your remarks to issue EXM-32599. But right now I'm not inclined in working on this. Fixing this is not trivial, people would need to probably opt in or out of this feature, most XML refactoring scripts are simple and do not need class matches and the end benefit would be that in some few cases like yours the matches would be simpler instead of matching multiple elements derived from a base you would match the base class attribute value. Yes, the XSLT would look more elegant this way.

Regards,
Radu

[chrispitude]

In Oxygen XML Editor, do interactively run refactoring operations have a different @class attribute behavior? I noticed when I was playing around with a test .dita and .xsl file in the XSLT Debugger perspective, that @class was populated in the right-side output:

image.png (172.28 KiB) Viewed 839 times

Does an interactively run XSLT stylesheet go through a different code path that retains @class attributes, perhaps because the output is not saved back to disk? I checked the XSLT Debugger perspective documentation but I did not see anything about attribute behaviors.

[Radu]

Hi Chris,

XSLT processing usually parses the XML document using the Xerces parser. The Xerces parser removes the DOCTYPE declaration and also adds default attribute values to the parsed XML document while it's being parsed. We've enriched the parser to do the same for the xml-model processing instructions pointing to RNG schemas.
But for XML refactoring we do not want the schema references to be removed when applying the XSLT and we also do not want default attribute values from the schema to appear in the XML document so we take out from the XML document the schema references (DOCTYPE, xml-model), we apply the XSLT processing and then add the schema references back to the resulting XML doc.

Regards,
Radu

[chrispitude]

Hi Radu,

That makes complete sense now. Thanks!