GH-187: Revise sameValue; produce error for 'don't know'

[afs]

• Produce an error as the last outcome
• Remove step containing "a datatype that is not handled by the SPARQL processor"
• Reorder to put literal handling together
• Handle the case of exactly one triple term

---

Preview | Diff

[kasei]

I think we need an addition to the "Normative changes" changes list in section "A. Changes between SPARQL 1.1 Query Language and SPARQL 1.2 Query Language". There are already mentions of sameValue in both the editorial changes and the errata sections, but the change that caused me to open #340 is not editorial, and I don't believe it is the same issue as that being raised by erratum clarification-query-3. I would suggest new normative change:

<li>Update <a href="#func-sameValue" class="sectionRef"></a> definition regarding literal arguments of differing types that are known to be not equal</li>

[TallTed]

It would be good if all the notes & examples that follow as part of this subsection could be included in this PR.

For instance, I would suggest some tweaks to —
For xsd:double and xsd:float, +0, -0 and 0 are same value.
— to make it —
Within each of xsd:double and xsd:float, +0, -0, and 0 are same value.
— or —
Within each of xsd:double and xsd:float, values +0, -0, and 0 are the same.

It might be even better to split the latter into two statements, i.e. --
For xsd:double, values +0, -0, and 0 are the same.
For xsd:float, values +0, -0, and 0 are the same.
-- and/or to add similar statements for any other datatypes where +0, -0, and 0 might be distinguished or explicitly treated as the same ... or make these statements match the earlier ones, a la —
sameValue treats the values of "0"^^xsd:double, "-0"^^xsd:double, and "+0"^^xsd:double as the same.
sameValue treats the values of "0"^^xsd:float, "-0"^^xsd:float, and "+0"^^xsd:float as the same.

Relatedly, can not would generally be better cannot, throughout.

[afs]

For instance, I would suggest some tweaks to —
For xsd:double and xsd:float, +0, -0 and 0 are same value.
— to make it —
Within each of xsd:double and xsd:float, +0, -0, and 0 are same value.
— or —
Within each of xsd:double and xsd:float, values +0, -0, and 0 are the same.

The statement is true across float and double. "+0"^^xsd:float is the same value as "-0"^^xsd:double. "Within each of" suggests to two separate cases.

[afs]

I think we need an addition to the "Normative changes" changes list in section "A. Changes between SPARQL 1.1 Query Language and SPARQL 1.2 Query Language". There are already mentions of sameValue in both the editorial changes and the errata sections, but the change that caused me to open #340 is not editorial, and I don't believe it is the same issue as that being raised by erratum clarification-query-3. I would suggest new normative change:

<li>Update <a href="#func-sameValue" class="sectionRef"></a> definition regarding literal arguments of differing types that are known to be not equal</li>

Entry added to cover both equal and not equal.

[TallTed]

The statement is true across float and double. "+0"^^xsd:float is the same value as "-0"^^xsd:double. "Within each of" suggests to two separate cases.

It was not clear to me what was meant by the original statement. Perhaps one of the following (I have some preference for the second) would be acceptable? (Possibly replacing Across in the first with Betwixt and between?)

Across the xsd:double and xsd:float types, +0, -0, and 0 are the same value.

sameValue treats the values of "0", "-0", and "+0", in both xsd:double and xsd:float, as the same.

I don't know whether it will make any difference to readers if the three zeros are wrapped in double-quotes or not.

[afs]

sameValue treats the values of "0", "-0", and "+0", in both xsd:double and xsd:float, as the same.

Better but it implies that this is a sameValue feature. This NOTE is merely calling out a fact about XSD/F&O.

Would this work?

For floating point datatypes (xsd:float, xsd:double) +0, -0 and 0 are the same value.

It would be good if all the notes & examples that follow as part of this subsection could be included in this PR.

This PR is about changing sameValue to produce an error, consequences there of, and a fix for one triple term.

Can we agree that to merge this PR and take improvements to NOTEs to a separate PR?

[lisp]

i realize that you have merged this, but when i read the version which resulted, i do not understand the significance of item 5. it is subsumed by 7,8, and 9.

[afs]

i realize that you have merged this, but when i read the version which resulted, i do not understand the significance of item 5. it is subsumed by 7,8, and 9.

Yes, given a certain reading of "determine their values". I think it is better to leave "determine" for extensions and specifically call out the handling of ill-typed literals, rather than cover extension and the fundamental ill-typed under "determine".

"Determine" is "by any means" and might be read to allow "10,000,000"^^xsd:integer, with knowledge that the locale thousands separator is , or scientific notation for xsd:decimal (current PubChem has about 2000 occurrences of this).

It also gives a place to link to ill-typed.

The text "If term1 and term2 are both literals", by the time of point 5, is also strictly unnecessary but helps clarity.