A question on how users are using <xsl:message > 2006-12-12 - By Mike Brown
Brian Minchau wrote:
> I know that Xalan has some extension attributes for xsl:output ... but now
> that I think about it ... where in XSLT 1.0 recommendation does it say that
> this is OK?
XSLT section 2.1:
"An element from the XSLT namespace may have any attribute not from the XSLT
namespace, provided that the expanded-name of the attribute has a non-null
namespace URI. The presence of such attributes must not change the behavior of
XSLT elements and functions defined in this document. Thus, an XSLT processor
is always free to ignore such attributes, and must ignore such attributes
without giving an error if it does not recognize the namespace URI. Such
attributes can provide, for example, unique identifiers, optimization hints,
or documentation."
So, you can add extension attributes as long as they don't change the
specified behavior of the element. So for example it is wrong (even though
Saxon does it) to have an extension attribute on a non-empty XSLT 1.0
xsl:variable element that causes it to create a node-set instead of a result
tree fragment. But having xalan:location-info="no" on xsl:message wouldn't be
harmful or against spec.
I agree though that it'd likely be something people would want to control
globally, as well as per-message.
As for what I use xsl:message for:
- debugging: often doing copy-of on a variable to see what it is
- tracing: "got here"/"now doing X" kinds of messages that I want to be logged
- validation: abort processing if crucial info missing; warn re: other issues
Also in the debugging and validation veins, I often write stylesheets that
walk a tree and process whatever is found. I'll set up templates to handle
certain nodes, and a generic template that handles anything I forgot to create
a more explicit template for. In that generic template will be an xsl:message
saying something to the effect of "FIXME". A top-level param might be used to
control whether the xsl:message is actually invoked.
Mike
|
|
