-
Notifications
You must be signed in to change notification settings - Fork 15
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
String comparison in deep-equal #934
Comments
Related: we say
I need to check this, but I think that whitespace text nodes will be removed from elements with element-only content model during the schema validation process even if |
Also closely related: the current rules for string comparison under whitespace normalization are non-transitive. This is because whitespace normalization is not applied to anyURI values. Currently, if the whitespace='normalize' option is set, then
This makes it very hard to implement unordered comparison (option ordered="false", or the implicit unordered comparison for attribute nodes) because it's not enough to find a matching pair of values from the two sequences and then compare the items that remain; you have to consider the possibility that there might be a different pairing of the two sequences that works. This is the only case of non-transitivity that I have found, but there may be others. This one is easily fixed by saying that whitespace normalization should be applied when comparing strings and URIs. (Of course, we depend on the collation being transitive. Perhaps we should state this as an explicit assumption/dependency. I believe that the UCA is designed to be transitive). |
The
to: F. Let T be true if the typed-value option is true and both attributes have a type annotation other than xs:untypedAtomic. Then either T is true and the typed value of $i1 is deep-equal to the typed value of $i2, or T is false and the equal-strings function returns true when applied to the string value of $i1 and the string value of $i2. This parallels the rule for element nodes, where typed-value comparison takes place only if the actual nodes to be compared are typed. |
@michaelhkay The test suite contains |
Two more questions. The current rules in the spec are as follows:
I assume that with new rules, Next, is it correct that the following query is expected to return deep-equal(
<x>A<?_?>{ ' ' }<?_?>C</x>,
<x>A C</x>,
options := map { 'whitespace': 'strip' }
) |
…and one more (sorry): Isn’t |
The code showing how strings should be compared in deep-equal has gone awry, it doesn't match the prose. In equal-strings(), the lines
should read:
Actually, the whole thing can now be expressed more concisely using fn:chain:
The text was updated successfully, but these errors were encountered: