Re: [xsl] is xslt "canonicalizable" can it be canonicalized?

["BR Chrisman brchrisman@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Feb 7, 2023 at 9:06 PM Liam R. E. Quin liam@xxxxxxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> On Wed, 2023-02-08 at 01:38 +0000, BR Chrisman brchrisman@xxxxxxxxx
> wrote:
> > transform.
>
> There are differences indeed, in the handling of namespaces between
> these two examples.
>
> I think with XSLT 3 at least, you can turn literal element constructors
> into element constructors (the xsl:element form), with careful use of
> exclude-result-prefixes.
>
> But not the other way round - consider
>    <xsl:element name="{$name}">
> for example. You can't write
>    <{$name}>
> to make an element, as that's not well-formed XML syntax.
>
> So likely you're stuck handling all of XSLT. But, why are you
> processing XSLT with XSLT in this way? Sounds interesting, tell us
> more! :)
>
>
I've had an interest in this before, but this particular application is a
bunch of fairly straightforward xslt (identity transform based pipelines)
and various pieces are introducing attributes into certain elements.  I
used an xpath to find most of the xsl:attribute elements creating those
attributes, but noted that I also needed to find the <foo bar="baz"/>
output elements that include the bar attribute in that form.  That's not
too hard, but if there was a canonicalization already out there, I'd use it.
Yes, that would certainly fail or be extremely difficult for attributes
named with the attribute-value-template style and variables/expressions in
a highly normalized template.  I have some of that in various stylesheets,
but not in the points of interest.


> liam
>
> --
> 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