SQF and DITA classes

[tcleghorn]

I'm struggling to formulate a Schematron Quickfix that can replace the value of a class attribute with the correct syntax for DITA - it seems to unavoidably strip the required trailing space character.
My current code:

Code: Select all

<xsl:variable name="foo" as="attribute(@class)+' select="doc('lookup.xml')/elements/@class"/>

[...]

<sch:rule context="*[@class]">

    <sch:assert sqf:fix="qux" test="@class = $foo">The class value isn't in $foo but should be</sch:assert>

</sch:rule>

[...]

<sqf:fix id="qux" use-for-each="$foo">

    <sqf:description>

        <sqf:title>Replace class value with "<xsl:value-of select="string($sqf:current)"/>

    </sqf:description>

    <sqf:replace match="@class" target="{'class'}" node-type="attribute">

        <xsl:value-of select="string($sqf:current)"/>

    </sqf:replace>

</sqf:fix>

This works, in as much as the assert fires when a class value is not in $foo, and Oxygen offers the valid class values in an SQF popup. However, it seems that the sqf:replace action normalises whitespace, so for example "- topic/topic special/element " becomes "- topic/topic special/element", which is not valid for DITA. What I'm really puzzled about is that the value-of in sqf:title correctly evaluates as "- topic/topic special/element " in the SQF popup.

My suspicion is that this is something to do with attribute-value normalisation - "If the attribute type is not CDATA, then the XML processor MUST further process the normalized attribute value by discarding any leading and trailing space (#x20) characters...", and DITA class attributes are indeed of type CDATA - but I can't figure out a way of confirming this for sure.

I wondered if using XSLT constructors inside the SQF actions - something like this:

Code: Select all

<sqf:replace [...]><xsl:attribute select="$sqf:current"/></sqf:replace>

- would get me where I needed to be, but this just results in the attribute being removed entirely from the document. I can live with the behaviour as it is, but if there's a way to retain the space, I'd really appreciate hearing about it!

[Radu]

Hi Tom,

My colleague Octavian who implemented the quick fix functionality reproduced the behavior starting from your example and indeed it seems we have a small bug on our side because Oxygen is trimming spaces before and after the attribute value before inserting it. We'll work on our side to fix this.

About your use case, what you are doing is quite strange as with DITA most of the times the @class attribute values are set as default values in the DTDs and no end user should attempt to set such values manually on the elements. Could you elaborate a little bit?

Regards,
Radu

[tcleghorn]

Yep, it's a weird thing to be doing - long story Essentially, we need some preliminary content that will eventually be converted to use new specialisations that we don't yet have. Since they're mainly specialisations of topic/section, we needed a way to have the author specify the intended new section now - when they can't yet use anything other than plain topic elements - using SQF to offer a list of permitted new class values (which we've already defined) is what we arrived at, since it gives us this pre-labelling without knocking any validation off-balance in our current tooling. Outputclass or otherprops would've maybe been easier to work with, but we've got some complicating factors in our existing usage of them; processing instructions would've been the second choice - we might fall back to them instead.

Thanks for looking into the attribute issue - it's at least good to know there's no point me spending more time trying to work around it!

[Radu]

Hi Tom,

Quite an interesting use case

Regards,
Radu