MCR-3719 Transition property.xsl to a pure XSLT3 environment

[toKrause]

Link to jira.

Pull Request Checklist (Author)

Please go through the following checklist before assigning the PR for review:

Ticket & Documentation

• The issue in the ticket is clearly described and the solution is documented.
• Design decisions (if any) are explained.
• The ticket references the correct source and target branches.
• The fixed-version is correctly set in the ticket and matches the PR's target branch (main).

Feature & Improvement Specific Checks

• Instructions on how to test or use the feature are included or linked (e.g. to documentation).
• For UI changes: before & after screenshots are attached.
• New features or migrations are documented.
• Does this change affect existing applications, data, or configurations?
  • Yes: Is a migration required? If yes, describe it.
  • Breaking change is marked in the commit message.

usage of mcrproperty:one needs to be replaced with mcrproperty:get
usage of mcrproperty:all needs to be replaced with mcrproperty:map

Testing

• I have tested the changes locally.
• The feature behaves as described in the ticket.
• Were existing tests modified?
  • Yes: explain the changes for reviewers.

MCR Conventions & Metadata

• MCR naming conventions are followed
• If the public API has changed:
  • Old API is deprecated or a migration is documented.
  • If not, no action needed.
• Java license headers are added where necessary.
• Javadoc is written for non-self-explanatory classes/methods (Clean Code).
• All configuration options are documented in Javadoc and mycore.properties.
• No default properties are hardcoded — all set via mycore.properties.

Multi-Repo Considerations

• Is an equivalent PR in MIR required?
  • If yes, is it already created?

To be used in conjunction with MyCoRe-Org/mir#1387.

[sebhofmann]

Removing dead code like mcrproperty:all is fine.

Introducing a breaking change just for an esthetic change (renaming one to get) is to much.

[toKrause]

Introducing a breaking change just for an esthetic change (renaming one to get) is to much.

If the mid-term goal is to remove top-level-xsl:param with function-calls, we should, imho, clean this up now, before the function is widely used.

We could add get as an additional function and remove one in the next release, giving people some time to migrate, like we do with the Java-code. But, afaik, there is no way to mark a XSLT function as "deprecated".