Skip to content

Fix semanticId matching: tolerate trailing eCl@ss/IRDI version suffix#8

Open
opendpp-node wants to merge 1 commit into
CIRPASS-2:mainfrom
opendpp-node:fix/semanticid-version-suffix
Open

Fix semanticId matching: tolerate trailing eCl@ss/IRDI version suffix#8
opendpp-node wants to merge 1 commit into
CIRPASS-2:mainfrom
opendpp-node:fix/semanticid-version-suffix

Conversation

@opendpp-node

Copy link
Copy Markdown

Fix: semanticId matching misses trailing eCl@ss/IRDI version suffixes

Fixes #7.

The bug

AasExtractorStrategy.matchesSemanticId documented itself as "suffix-insensitive to
tolerate version suffixes (e.g. #2)"
, but the implementation

candidate.equalsIgnoreCase(target) || candidate.toUpperCase().endsWith(target.toUpperCase())

only tolerates a leading IRI prefix. A real-world versioned value ends with the version,
not the target:

AAS semanticId.keys[].value configured target old result
0173-1#02-AAW338#001 0173-1#02-AAW338 ✗ miss
https://…/0173-1#02-AAW338 0173-1#02-AAW338

So version-less configured targets (the pattern the bundled configs deliberately use) never
matched versioned AAS values, and extraction silently fell back to idShort-path
navigation — or missed entirely when idShorts are vendor-specific. Notably, the existing
dpp-aas.json fixture already carries versioned semanticIds (…#001, …#012, …#003);
its test passes only because the standard idShorts let the fallback rescue it.

The fix

Also compare the candidate with a trailing #NNN segment stripped — only when another #
remains after stripping, so plain IRIs with a numeric fragment are left untouched. Pinned
(versioned) targets keep their exact-match semantics; existing behaviour is otherwise
unchanged (the old comparison still runs first).

Regression test (red → green)

dpp-aas-versioned.json: same data as dpp-aas.json, but with vendor-specific idShorts
and versioned eCl@ss semanticIds — so the idShort fallback cannot mask the bug and extraction
must succeed via the semanticId scan alone (granularity, configured by idShortPath only,
keeps its standard idShorts and keeps working).

  • Before the fix: expected: <4> but was: <1> (only granularity extracted)
  • After the fix: full suite green — SearchKeyExtractorTest: tests=5, failures=0, errors=0
    (4 existing + 1 new), all modules (./mvnw test, JDK 21).

Checklist

  • Bug fix includes a test that verifies the fix (fails before, passes after)
  • Existing test suite passes (full reactor)

— Giovanni Savastano · OpenDPP (opendpp-node.eu)

matchesSemanticId documented itself as version-suffix tolerant, but
endsWith only tolerates a LEADING IRI prefix: a real-world versioned
value like 0173-1#02-AAW338#001 ends with CIRPASS-2#1, so a version-less
configured target never matched and extraction silently fell back to
idShort-path navigation (or missed entirely with non-standard idShorts).

Also compare the candidate with a trailing #NNN segment stripped (only
when another '#' remains, so plain IRIs with numeric fragments are left
untouched). Regression test: dpp-aas-versioned.json carries versioned
eCl@ss semanticIds AND vendor-specific idShorts, so it can only pass via
the semanticId scan (fails with 1/4 fields before this fix).

Fixes CIRPASS-2#7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AAS semanticId matcher: version-suffix tolerance looks inverted (endsWith misses trailing #NNN)

2 participants