Formatter / Full view missing/extra matching nodes#9203
Open
fxprunayre wants to merge 1 commit intomainfrom
Open
Formatter / Full view missing/extra matching nodes#9203fxprunayre wants to merge 1 commit intomainfrom
fxprunayre wants to merge 1 commit intomainfrom
Conversation
fxprunayre force-pushed the 44-formatterdeepequal branch 2 times, most recently from e16ce57 to 4fe4fc4 Compare 
joachimnielandt approved these changes Mar 17, 2026
Contributor
joachimnielandt left a comment
joachimnielandt left a comment There was a problem hiding this comment.
Tested locally for DCAT record that has two equal LicenseDocuments on DataService and Catalog levels.
fxprunayre force-pushed the 44-formatterdeepequal branch from eae176d to cda303f Compare 10 tasks
In #9000, we added a tentative fix for improving labels when translations contains labels with xpath context. eg. ```xml <element name="gmd:description" context="/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:description"> <label>Beschrijving temporele dekking</label> <description>temporele dekking van de data, gespecificeerd als een periode.</description> </element> ``` This was not working due to the formatter reading the editor config, find matching field/section to render using saxon `evaluate` function. One drawback is that when using this function, the returned node does not have its context (eg. `..` to get its parent). So the logic to get label based on xpath can't work. To avoid this a check was made to retrieve the corresponding the original node in the document and `deep-equal` function was used for that. But we noticed some case not handled * #9163 2 sections matching the xpath of the editor config (due to wrong usage of deep-equal) * More than one node matching at different location in the document (eg. a DCAT-AP document with the same license in Catalog and Service will display the 2 license for the service). * No matching element when using a section with a forEach attribute. Note: In edit mode, unique ref in `gn:element` is used to retrieve original node which is more reliable but can't be used in view mode. Proposal is to find the original node using `deep-equal` and then checking using node xpath matching when the xpath does not make use of wildcard. If wildcard, then `evaluate` returned nodes are used (and may cause the label issue). Related * #9000 * #9163
fxprunayre force-pushed the 44-formatterdeepequal branch from cda303f to b18b2ef Compare 
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In #9000, we added a tentative fix for improving labels when translations contains labels with xpath context.
eg.
This was not working due to the formatter reading the editor config, find matching field/section to render using saxon
evaluatefunction. One drawback is that when using this function, the returned node does not have its context (eg...to get its parent). So the logic to get label based on xpath can't work.To avoid this a check was made to retrieve the corresponding the original node in the document and
deep-equalfunction was used for that. But we noticed some case not handleddct:rightsis not rendered).Note: In edit mode, unique ref in
gn:elementis used to retrieveoriginal node which is more reliable but can't be used in view mode.
Proposal is to find the original node using
deep-equaland then checking using node xpath matching when the xpath does not make use of wildcard. If wildcard, thenevaluatereturned nodes are used (and may cause the label issue).Related
Checklist
mainbranch, backports managed with labelREADME.mdfilespom.xmldependency management. Update build documentation with intended library use and library tutorials or documentation