[xslt] annotation-prefixes

[liamquin]

By analogy with Schema annotations, i'd like to see an annotation-prefixes attribute on xsl:stylesheet/transform containing a space-separated list of NCName namespace prefixes that are associated with annotations; the XSLT processor would discard these elements (including children) during compilation. Here's a rough go at some text.

The purpose is to be able to include annotations at any level where elements are allowed - for example, inside an xl:variable or template or function body. Annotations might include XTest unit tests, Schmatron rules, human-readable documentation, CSS styles, or more, and could be used by other operations than the XSLT transformation: for example, by processing the XSLT source itself with XSLT.

It should be possible for the same element to be both an extension element and an annotation, but the behaviour is implementation-dependent in this case (for example, an API might allow an extension to access content or convert the annotation elements to something else on compilation).

XSLT instructions occurring inside annotation elements are ignored along with other content, except for xsl:fallback instructions (and their contents) if the prefix was also declared as an extension prefix and no matching extension was found. Similarly, extension attributes are discarded. The fallback behaviour might be used to support an XSLT-based implementation, for example by reading the XSLT source and processing embedded Schematron tests.

Attributes of annotation elements are not considered to be attribute value templates and content is not considered to be text value templates - that is, { and } are not special. However, an annotation element or attribute backed by an extension could perform such processing if an implementation supported it. The behaviour of shadow annotation attributes and xsl:use-when is implementation defined, but expressions contained in them must be processed as elsewhere.

[michaelhkay]

I did actually experiment with this idea (I called it documentation-prefixes) but didn't pursue it because the details got quite complicated (like everything to do with namespaces). Although I didn't take it quite as far as this; my main aim was to ensure that namespaces declared only for use in top-level "data elements" had no effect on run-time execution (exclude-result-prefixes stops them being used by literal result elements, but not by other things that use the static namespace context at run-time, e.g. the xs:QName() constructor function).

[liamquin]

On Fri, 2020-12-18 at 14:31 -0800, Michael Kay wrote: I did actually experiment with this idea (I called it documentation- prefixes) but didn't pursue it because the details got quite complicated 

I'd be fine with calling it documentation-prefixes; i did not consider xsl:element, but that's because i was thinking of them as a sort of extension instruction, and was trying to do the simplest proposal that would seem to support these use cases. If i construct an xsl:variable element with a name attribute set to v, i don't expect the name to become visible as $v either.

…

-- Liam Quin, https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org

[michaelhkay]

This issue can be closed following adoption of PR #353 (xsl:note)