XSLT on-no-match="shallow-copy-all" - revised rules #1238
Labels
Enhancement
A change or improvement to an existing feature
PRG-easy
Categorized as "easy" at the Prague f2f, 2024
PRG-required
Categorized as "required for 4.0" at the Prague f2f, 2024
XSLT
An issue related to XSLT
The work on deep lookup with modifiers enables an improved set of rules for processing trees of maps and arrays using a mode with
on-no-match="shallow-copy-all"
.Recall that the intent is that if the user writes no template rules at all in such a mode, the effect is to recursively copy the entire structure without change. But it should be as easy as possible for the user to add template rules to override this processing for a selected part of the structure.
With this in mind, the proposed built-in rules are as follows:
For an array with no additional information available, we split it up into array members in a way that makes it possible to override
the processing for a specific array member:
The field 'array-member' here is a dummy, provided simply to make it easier to match these records at the next level of processing.
For the array members, when represented in this way, the items in the array member are processed one-by-one to produce
a new array member:
The new array members are delivered as singleton maps, in the form expected by the match="array(*)" template given above.
For the individual items within each array member, the default is simply to apply-templates to the item:
Similarly for a map with no additional information, we reconstruct the map by applying templates to its individual entries:
The built in processing for a map entry represented in this way is to reconstruct the map entry by applying templates to its individual items:
For the individual items within each map entry, the default is simply to apply-templates to the item:
And of course the fallback processing for items not in the above list is to return them unchanged:
This allows user-written template rules to intervene at any of these levels, and to have access to contextual information about the item they are processing. For example to rename map entries with key "comment" to have key "note" instead, use:
There's one more refinement I would like, which is to provide access to the selection path for each map and array entry. I think this can be done by ensuring that within the template, items are labeled so that the function call selection-path(?value) or selection-path(?item) delivers the required result.
The text was updated successfully, but these errors were encountered: