feat: support Text Value Templates (expand-text)

[AirQuick]

This pull request introduces a feature just like XSLT 3.0's Text Value Templates.
Enabling/disabling TVT is controlled by @expand-text (or @x:expand-text in user-content).

Example

<test> in

<x:context expand-text="yes">
  <test>{1 to 9}</test>
</x:context>

is expanded to

<test>1 2 3 4 5 6 7 8 9</test>

Commits

• e364e26 defines @expand-text.
  • This attribute can be set on any x:* elements, like XSLT's @expand-text.
  • I verified that the attribute's annotation is displayed when a mouse pointer hovers over @expand-text on Oxygen.
• bb5547a allows common-attributes on x:text.
• e614e89 implements the feature.
  • The implementation is simple:
    • Resolve @expand-text in x:gather-specs mode
    • Pass the resolved @expand-text to the compiled XSLT in test:create-node-generator mode.
• 466eb13 tests the implementation.

Limitation

• Requires XSLT 3.0 processor
• Not implemented for XQuery, for lack of the language's simple support for TVT.
  • To help any future implementation, the relevant place is marked with TODO.

Further work

Document the feature briefly in Wiki.

[galtm]

@AirQuick , I've started reviewing this pull request. This enhancement looks very promising! I need more time (maybe a week or so) but just wanted you to know that my review is in progress.

[AirQuick]

Thanks @galtm It's always great to have a review. This pull request is unlikely to conflict with the others. It's ok to leave this opened for weeks.

[galtm]

I'm most of the way through this pull request. I think this feature is useful, well designed, and well aligned with how XSLT TVTs work.

Question: Is x:label supposed to allow @expand-text and support TVTs?

[galtm]

Is x:is-user-content(.) always true for text nodes in this template? Just asking so I understand. If it's not always true, though, can there be a test that exercises that situation?

[AirQuick]

Is x:is-user-content(.) always true for text nodes in this template?

You're right, in the current usage patterns.

test:create-node-generator creates a node generator. Callers of this mode may expect the created generator to do either of these two:

1. When executed, the generator always generates the source node exactly as it was.
2. When executed, the generator generates the source XSpec user-content node as its author indended.

I think that ideally,
(A) those two cases should be distinguished clearly,
and
(B) test:create-node-generator should be able to serve both cases.

(A) requires cooridation with the callers.
is-user-content(.) here is an attempt to satisfy (B) to some extent. It's incomplete but yet better than nothing until (A) is satisified.

If it's not always true, though, can there be a test that exercises that situation?

As you pointed out, test:create-node-generator should be coupled with tests. In fact, the whole generate-tests-helper.xsl as a module file should be tested. #729 is a small step toward it.

[galtm]

I finished looking at the files and don't have any further comments beyond what I posted earlier. Good feature, @AirQuick !

[AirQuick]

Thanks for the informative review, @galtm. I'll resume this pr after the release of v1.5.0 gets fixed.

[AirQuick]

And I think @expand-text should never enable TVT inside x:label because it will complicate resolving x:like. I'll add a test for it, after resolving #801.

Added 203fb29 (XSLT) and ad0d218 (Schematron).

[AirQuick]

fe4c509 revealed a bug: Whitespace-only text nodes outside user-content may be transformed into x:text, because x:gather-specs mode does not distinguish user-content clearly.
Fixed in 7372cb7 and 7097107.

[galtm]

FYI, I am planning to take another look at this PR over the weekend. You've made a lot of changes since my initial code review, so it seems like time for a fresh look.

[galtm]

Other than one correction in a label, I have no other comments. Everything looks good.

Your numerous test cases not only make the feature more solid, but they'll also come in handy for our future reference about how different situations are supposed to work.

[AirQuick]

Further work

Document the feature briefly in Wiki.

Done. (diff)

[AirQuick]

Now merged.
Thanks @galtm for the review. This would not have been possible without your help.