Function annotations in XSLT

[michaelhkay]

I propose that the following attributes on an xsl:function should be accessible as annotations, for example in a call on function-annotations:

• visibility
• streamability
• new-each-time
• cache

plus any extension attribute in a user-defined namespace, for example <xsl:function saxon:debug="yes"/> should have the annotation %saxon:debug("yes"). The value is always a single string, the actual attribute value as written.

[Arithmeticus]

What about also @use-when, to identify functions that potentially overshadow each other?

[michaelhkay]

Eh? If @use-when is false, the code to create the function is never even read. If a function makes it into the world, then @use-when was true by definition.

But perhaps you mean something different, like functions being excluded because of import precedence? Again, the function will have been discarded - you can't ask questions about functions that aren't visible because we throw them away as soon as we realise.

[dnovatchev]

I propose that the following attributes on an xsl:function should be accessible as annotations, for example in a call on function-annotations:

Compare this to being able to modify the behavior of any function in any wanted way, that has never before been planned for, and therefore never specified and documented in any specification document or via any extension attribute.

Of course, I am talking about decorators.

If we have decorators in XPath then there will be no need for annotations and no user will ever have to wait until Saxonica or any other implementor produces a desired new feature via an extension attribute.

Instead, the user will spend just a few minutes to create the desired decorator and then decorate the functions of interest with it.

This is a win-win situation for everybody:

• Users are happy and not locked-into a particular vendor.
• Users implement the desired behavior in minutes and don't have to wait for months and years for the mercy of a particular implementor.
• Users don't have to beg or persuade implementors that the desired new behavior is important.
• A lot of time and resources are saved and not wasted.
• Implementors don't have to argue with users whether or not a proposed new feature is useful.
• Implementors don't have to implement any user's whims.
• Specifications would be significantly slimmer without such added "standard" features.
• Specifications would be thus possible to read and easier to understand, and not repelling.
• Designers of the language will be able to offload themselves of many minor new-features proposals, and will have more time and chances of doing more creative work.