Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the concept of equality in p:wrap, p:wrap-sequence etc. #302

Closed
xml-project opened this issue Dec 20, 2019 · 7 comments · Fixed by #315
Closed

Clarify the concept of equality in p:wrap, p:wrap-sequence etc. #302

xml-project opened this issue Dec 20, 2019 · 7 comments · Fixed by #315
Assignees

Comments

@xml-project
Copy link
Contributor

@xml-project xml-project commented Dec 20, 2019

Currently we say:

The specified XPath expression is evaluated for each matching node with that node as the XPath context node. Whenever two or more adjacent matching nodes have the same “group adjacent” value, they are wrapped together in a single wrapper element.

As @ndw and I found out, the concept of having "the same group adjacent value" is ambiguous because it could either mean that the two values are equal or that they are deep-equal.

Remember there are differences between the two concepts as "() = ()" is false(), but "deep-equal((),())" is true. Furthermore " = " is true(), but "deep-equal(, ) is false().

Any opinion which concept of "same value" we want here?

@gimsieke

This comment has been minimized.

Copy link
Contributor

@gimsieke gimsieke commented Dec 20, 2019

Hmm, in XSLT’s for-each-group/@group-adjacent the expression must result in exactly one atomic value (for @group-by, there can be multiple result values), and these atomic values are compared using deep-equal.

Do we also require that the group-adjacent expressions, after atomization, yield exactly one atomic value? If we have only a single value, equal and deep-equal are the same.

The spec says “Whenever two or more sequentially adjacent documents have the same “group adjacent” value, …”

This might imply that we expect our group-adjacent expression to also return exactly one value.

If we permit sequences as expression results, we should nevertheless say that they be atomized. And then they should be compared using deep-equal().

@xml-project

This comment has been minimized.

Copy link
Contributor Author

@xml-project xml-project commented Dec 20, 2019

If we permit sequences as expression results, we should nevertheless say that they be atomized.

Why? Doesn't that exclude maps, functions and arrays as values because they can not be atomized?

@ndw

This comment has been minimized.

Copy link
Collaborator

@ndw ndw commented Dec 20, 2019

What plausible use case for wrapping a sequence requires a map, array, or function as a group-adjacent value?

@xml-project

This comment has been minimized.

Copy link
Contributor Author

@xml-project xml-project commented Dec 20, 2019

What reasons to exclude them?

@ndw

This comment has been minimized.

Copy link
Collaborator

@ndw ndw commented Dec 21, 2019

I don't feel strongly about it. I'm happy to say deep-equal is the answer, consistent with XSLT. I'd be equally happy to say that exactly one value must be returned, but I don't feel strongly about that either.

(Achim, you seem to have written the ab-wrap-sequence-014 test such that it's not a deep-equal comparison; so I wonder if we've both changed our minds! 😄 )

@gimsieke

This comment has been minimized.

Copy link
Contributor

@gimsieke gimsieke commented Dec 21, 2019

I don’t have a strong opinion either. There may be a slight benefit in aligning with XSLT, in order to reduce the mental strain on XSLT/XProc programmers.
If one method was easier to implement for an XProc processor, this would also make a case for it. But since deep-equal() on any kind of XDM 3.1 items is available to each implementation, this shouldn’t be a criterion.

@ndw

This comment has been minimized.

Copy link
Collaborator

@ndw ndw commented Dec 21, 2019

Here's an observation: if we use deep-equal() and you happen to want an atomic comparison, you can atomize. If we use eq or = and you want a deep-equal() comparision, you're out of luck.

I think that persuades me that we should use deep-equal().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.