Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shallow copy in XSLT with maps and arrays #1777

Open
michaelhkay opened this issue Feb 6, 2025 · 2 comments
Open

Shallow copy in XSLT with maps and arrays #1777

michaelhkay opened this issue Feb 6, 2025 · 2 comments
Labels
Enhancement A change or improvement to an existing feature Reviewed-required Triage suggests this issue must be resolved for 4.0 XSLT An issue related to XSLT

Comments

@michaelhkay
Copy link
Contributor

michaelhkay commented Feb 6, 2025

Currently the xsl:copy instruction, if applied to a map or array, does a deep copy, and ignores the content of the contained sequence constructor.

I propose that if the contained sequence constructor is non-empty then instead of ignoring it, we should use it to create the content of the new map or array. Specifically, for maps xsl:copy will behave essentially like xsl:map, and for arrays it will behave essentially like xsl:array.

This is an incompatibility with 3.1, but since a contained sequence constructor is currently totally useless in this situation, it doesn't seem likely to cause any trouble.

I also propose that rather than using the new built-in on-no-match="shallow-copy-all, we should extend the semantics of shallow-copy to cover maps and arrays (as currently defined for shallow-copy-all). Again, there is an incompatibility, but the current rules are so unhelpful that it's unlikely people are relying on them.

I also propose that when apply-templates is applied to a map or array, it should be automatically pinned if it is not pinned already. The means that match patterns can be used with a lot more context to match the deep contents of the map or array and override the processing of the built-in templates.

And I propose that when apply-templates is applied to a map or array and there is no select attribute, it should "do the right thing" by applying templates to the map or array contents, rather than using the useless default of child::node().

@michaelhkay michaelhkay added XSLT An issue related to XSLT Enhancement A change or improvement to an existing feature labels Feb 6, 2025
@ndw ndw added the Reviewed-required Triage suggests this issue must be resolved for 4.0 label Feb 11, 2025
@michaelhkay
Copy link
Contributor Author

As regards the built in template rule for shallow-copy with maps and arrays:

  • The first principle is that if you don't write any template rules at all, you always end up with a (deep) copy of what you started with.

  • It's a general principle that within a mode, all the template rules should return similar values so that they can be used interchangably.

  • The most likely way for users to override this processing is with template rules of the form match="?key" as proposed in XSLT templates: Matching values in a map by key #1795.

The built-in template needs to do something like this:

* If processing an item with an associated key (in its label)
** Generate a map entry having the same key
** If the value is a map, apply-templates with select = ?* to construct the entry
** if the value is an array, do <xsl:array><xsl:apply-templates select="?*/><xsl:array>
** otherwise, copy the value to the new entry
* If processing an item with no associated key
** If the value is a map,  do <xsl:map><xsl:apply-templates select="?*/><xsl:map>
** if the value is an array, do <xsl:array><xsl:apply-templates select="?*/><xsl:array>

That's a significant departure from the current spec.

@michaelhkay
Copy link
Contributor Author

See also #1238 which complements this line of attack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement A change or improvement to an existing feature Reviewed-required Triage suggests this issue must be resolved for 4.0 XSLT An issue related to XSLT
Projects
None yet
Development

No branches or pull requests

2 participants