TEDEFO-5169: Let the caller choose how much a joined path is simplified

[rousso]

Fixes TEDEFO-5169.

The problem

XPathProcessor.join shortens the path it produces: where a step is immediately followed by a step going back up, it removes both, so a/b/../c becomes a/c.

That shortening does not preserve meaning. The long form selects nothing when b is absent from the document; the short form selects c regardless:

<root><x>X</x><y>Y</y><z>Z</z></root>
   ../y/../z  ->  "Z"
   ../z       ->  "Z"

<root><x>X</x><z>Z</z></root>
   ../y/../z  ->  (nothing)
   ../z       ->  "Z"

The only caller is the EFX context override, context::field, which means the value of the field by a path that starts at the context. Where the context is not present in the notice there is no starting point, so there should be no value — and the shortening removes exactly that. Until now the library made that decision on the caller's behalf, and silently.

TEDEFO-5148 made the shortening stop at a step carrying a predicate, so the predicate would not be discarded with it. That left the behaviour uneven: the condition survives where the path happens to carry a predicate — which may come from fields.json rather than from anything an author wrote — and is lost where it does not.

What changed

The decision moves to the caller.

public enum Simplification {
  NONE,                 // every step is kept as it was written
  PRESERVE_PREDICATES,  // a step and a following parent step cancel out, unless the step carries a predicate
  FULL                  // they cancel out even then, and the predicate goes with the step
}

public static String join(String first, String second, Simplification simplification)

first	second	NONE	PRESERVE_PREDICATES	FULL
a/b	../c	a/b/../c	a/c	a/c
a/b[x]	../c	a/b[x]/../c	a/b[x]/../c	a/c
a	..[x]/b	a/..[x]/b	a/..[x]/b	b
a/b	../../c	a/b/../../c	c	c
a[x]/b	../c	a[x]/b/../c	a[x]/c	a[x]/c

join(first, second) delegates with PRESERVE_PREDICATES, so every existing caller behaves exactly as it does in 1.8.0. A missing setting is refused rather than falling into a default, since the setting decides how much of what the two paths said survives.

The javadoc now states plainly that simplifying is not meaning-preserving, and each enum value documents what it gives up. That was missing before, which is why a context override could lose its anchor with nobody noticing.

Predicates on steps that are not cancelled are preserved under every setting. That was the original defect in TEDEFO-5148 and is unaffected by this choice.

Verification

FULL reproduces 1.7.0's cancellation exactly. Checked against a clean build of the 1.7.0 tag over sixteen cases: the only differences are where 1.7.0 was itself wrong — a predicate lost from a step that was never cancelled, a lost leading separator, a stray leading slash — each of them a defect TEDEFO-5148 fixed.

mvn clean install passes with the binary compatibility gate active, 90 tests. The delta is additive: one new enum, one new overload, no existing signature or behaviour altered, so this is a minor release.

Impact

No SDK content is affected. Context overrides are not used in any released SDK — every occurrence of :: in 1.13.3, 1.14.2, 1.15.1, 1.16.0-beta.2 and 2.0.0-alpha.3 is the preceding axis. Nothing the SDK ships transpiles differently.

Next

1. Cut release/1.9.0: rewrite CHANGELOG.md for 1.9.0, documenting Simplification, and set the version.
2. Release and publish ECL 1.9.0.
3. TEDEFO-5170 in the EFX Toolkit passes Simplification.NONE for context overrides, and moves its dependency from 1.9.0-SNAPSHOT to 1.9.0.