fix(query): STR() on a double returns the canonical XSD lexical form

[aaj3f]

Fixes #1695.

STR() on an xsd:double was routing through Rust's Display, so STR(?d) came back "1" for the same term the serializer printed as "1.0E0" two fields over in the same result set — and "inf" for a value that no RDF format spells that way. #1445 fixed this for the six RDF output sites by adding canonical_xsd_double; expression evaluation was simply never on that list, so we've had two renderings of one concept since then.

The mechanism is the one the issue traced: ComparableValue::into_string_value (fluree-db-query/src/eval/value.rs) formatted the Double arm with d.to_string(). Rather than derive a second formatter next to it, fluree-db-query picks up a dependency on fluree-graph-ir and calls the serializer's own canonical_xsd_double — the same function export.rs, format/sparql.rs, format/sparql_xml.rs and format/delimited.rs already call. The TypedLiteral { val: FlakeValue::Double, .. } arm the issue flagged takes it too.

Two siblings turned out to be the same defect and are folded in:

• STR() on an xsd:float. There are two layers here. The visible one is the same as the double's: the serializer gave 1.0E0 where STR() gave 1. The subtle one is that a stored xsd:float is carried as a full-precision FlakeValue::Double (ingest never narrows), and expression evaluation narrows the binding to an f32 on the way into ComparableValue (lit_to_comparable, and the EncodedLit re-tag from query: xsd:float first-class on the EncodedLit (binary-store) path #1470) — which is right for arithmetic and datatype(), and irreversible for lexical purposes. For an f32-inexact value like "3.14159265358979"^^xsd:float the serializer prints the stored f64 (3.14159265358979E0), so no rendering of the f32 can ever agree with it. STR() therefore reads the stored f64 straight off the binding (stored_float_f64 in eval.rs, covering both the Lit and the late-materialized EncodedLit lanes) and renders canonical_xsd_double — exactly the serializer's string, and no widening artifact can arise there because that f64 was parsed from the lexical, never widened from an f32. A float computed inside an expression is a genuine f32 and renders canonical_xsd_float, which joins its sibling in fluree-graph-ir/src/xsd_double.rs — both share the one finite_canonical writer behind a small sealed XsdFloat trait that keeps the finite-input contract machine-checked (debug_assert!) and the NaN/INF/-INF spellings written exactly once, for the cast renderers too.
• GROUP_CONCAT's numeric coercion (aggregate.rs), which stringified doubles the same way — GROUP_CONCAT(?d) produced 1|1000000 where the serializer renders those same two terms 1.0E0 and 1.0E6.

One sibling I deliberately did not fold in, and I think this is the more interesting part of the PR. My first pass also routed the xsd:string() cast through the canonical form, on the theory that it was the same seam. The W3C suite said otherwise, and it's right: SPARQL §17.5 defers casting to XPath, whose float/double→string rule casts through xs:decimal — plain decimal notation — for absolute values in [1e-6, 1e6), and data-sparql11/cast/cast-string.srx requires xsd:string("1E0"^^xsd:double) to be "1", not "1.0E0". So the cast and STR() are answering genuinely different questions and need to stay apart. Since cast_to_string was reaching the canonical form only by falling through to into_string_value, it now has explicit Double/Float arms of its own (eval/cast.rs) — which also picks up the one part of the cast that was broken under every reading of the spec: it was emitting Rust's "inf"/"-inf" rather than INF/-INF.

But the XPath range rule is exactly that — a range, and it is two-sided: outside [1e-6, 1e6) XPath prescribes the canonical lexical representation, which with the canonical writers in hand is a two-line check rather than "implementing XPath's algorithm". So format_f32/format_f64 apply it: xsd:string(1.0E-7) is 1.0E-7 (not 0.0000001), just as xsd:string(1.0E30) is 1.0E30 (not a 31-digit integer). Nothing in the W3C corpus moves in either direction — the suite is 36/0 on both sides of the change; the cast columns in the tests pin both bounds.

The invariant that came out of all this, and the one the tests actually assert, is STR(?x) equals what we serialize for ?x — checked per-row against the serialized value of the same binding rather than against a hardcoded string, so the two paths can't drift apart again without a red test.

What stays open, deliberately, in #1776: the conflation underneath all three symptoms — float renderers keying on the Double variant rather than the declared datatype. Concretely: whether the serializer should print an xsd:float term at f32 precision at all (a user-visible output decision, same shape as #1445's); the group-key GROUP_CONCAT lane, whose aggregate input round-trips through to_binding and mints a third spelling; STR(COALESCE(?f)), which evaluates the inner expression to an f32 before STR() can see the binding; and the stored-vs-computed provenance split at to_binding (a computed float mints its XPath-cast lexical — each such term is internally consistent across serializer/STR/cast, and switching it to the canonical spelling would break xsd:string() on the rebound term, so it stays, documented at the site). The unreachable TypedLiteral { val: Double, .. } cast arm carries a guarding comment pointing at the same issue.

Follow-up: #1776.

Tests

• sparql_str_double_matches_serializer_canonical_form sits right beside the existing serializer pin sparql_double_canonical_lexical_form_across_formats, so the two can't drift. It covers the issue's repro (1E0), an integral value, both exponent directions, a negative, NaN/INF/-INF — and pins the cast column alongside on both sides of the XPath range (1.0E-7, 1.0E6, 1.0E30), precisely so the deliberate relationship between the two functions is stated rather than left for someone to "fix" later.
• sparql_str_float_matches_serializer_canonical_form includes f32-INEXACT rows (3.14159265358979, 1.23456789012345E-5) — the discriminating cases: an f32-exact row passes under any implementation, an inexact one only if STR() reads the stored f64.
• sparql_encoded_xsd_float_str_matches_serializer pins the same agreement on the late-materialized EncodedLit lane (reindexed ledger), next to the query: xsd:float first-class on the EncodedLit (binary-store) path #1470 re-tag tests it extends.
• sparql_group_concat_double_canonical_form for the aggregate sibling.
• jsonld_bind_str_double_canonical_form and jsonld_bind_str_float_canonical_form are the JSON-LD twins per the parity rule — (str ?d) gives the same canonical string while the value itself stays a native JSON number.
• Unit coverage on into_string_value and canonical_xsd_float in fluree-graph-ir, plus format_f32/format_f64 range pins (format_f64_xpath_range_is_two_sided) including the inclusive/exclusive bounds and zero.

Non-vacuity checked by revert, one lever at a time: with the eval_str fast path disabled, the inexact float rows and both float twins go red (left: "3.1415927E0" / right: "3.14159265358979E0") while the f32-exact rows stay green; with only the EncodedLit arm of stored_float_f64 disabled, the encoded-lane test goes red with the same truncation while the Lit-lane test stays green — proving that lane actually fires; with the cast range check disabled, the unit and integration cast pins go red (left: "0.0000001"). All green on restore.

Gates

-p fluree-db-query (1488 lib, all green), -p fluree-graph-ir (51), -p fluree-db-api grp_query_sparql (372) and grp_query (425), the W3C suite (36 passed; 0 failed), workspace check (minus the excluded search crates), clippy -D warnings clean on all three touched crates, cargo fmt --all last and testsuite-sparql's own fmt clean. No register movement in either direction — testsuite-sparql/tests/registers/mod.rs is untouched, which is the honest answer here: the cast register never moved because I corrected the scope rather than registering a regression.

[bplatz]

Approving — the double side is solid. I reproduced the gates locally (graph-ir + fluree-db-query --lib green, W3C 36/0, clippy/fmt clean) and the non-vacuity claim: both sparql_str_* tests go red on revert. Keeping the cast separate is the right call and well evidenced.

Please look at the inline points before merging, though — the float sibling isn't actually closed. STR() still disagrees with the serializer for any stored xsd:float that isn't f32-exact, and the new float test can't catch it. Some of the rest are probably follow-up issues rather than changes here; fine either way as long as they get filed.

[bplatz]

STR() on a stored xsd:float still diverges from the serializer. Floats are stored as FlakeValue::Double(f64) and ingest never narrows, so "3.14159265358979"^^xsd:float serializes as 3.14159265358979E0 while STR() returns 3.1415927E0 — coerce_numeric_operand's d as f32 truncates first. GROUP_CONCAT keeps the f64 and agrees with the serializer, so one term now has three renderings.

Simplest close: don't downcast on this path. canonical_xsd_double on the stored f64 matches the serializer exactly, and the widening artifact the new doc warns about can't arise here — the f64 came from parsing the lexical, not from widening an f32. The conflation underneath (serializers key on the Double variant, not the declared datatype) looks like follow-up issue material.

[aaj3f]

Right on the defect — and one refinement on the mechanism, because it ended up shaping the fix. For a stored float the truncation isn't in coerce_numeric_operand (that path only handles the string-backed cast/STRDT literals); it's at binding→ComparableValue conversion itself — lit_to_comparable (eval.rs) and the #1470 EncodedLit re-tag. Which means "don't downcast on this path" can't be done inside into_string_value: by the time the Float arm runs the f64 is gone, and widening it back is exactly the artifact case. And the general arm genuinely can't call canonical_xsd_double either — your "the f64 came from parsing the lexical" guarantee holds for a stored term, but a float computed inside the expression reaches the same arm as a widened f32, where 33.33f32 * 1 would spell itself 3.3330001831054688E1.

So the shape that landed: eval_str reads the stored f64 straight off the binding for the bare-variable shape (stored_float_f64 in eval.rs, covering both the Lit and EncodedLit lanes — same pattern as eval_lang's existing binding fast path), and renders canonical_xsd_double; computed floats keep canonical_xsd_float. Verified live: stored "3.14159265358979"^^xsd:float — serializer 3.14159265358979E0, STR() was 3.1415927E0, now equal, on both lanes.

One wrinkle your GROUP_CONCAT sub-claim surfaced when I ran it: it agrees with the serializer on the plain lane (GROUP BY ?s → agg_group_concat's Double arm → 3.14159265358979E0), but GROUP_CONCAT(?f) … GROUP BY ?f gives a third spelling, 3.1415927 — the group-key lane round-trips the aggregate input through expression eval → to_binding → format_f32. That one, plus STR(COALESCE(?f)) (the inner expression evaluates to an f32 before STR() can see the binding) and the serializer-precision question itself, are the umbrella you called: filed as #1776.

[bplatz]

All three cases are f32-exact, so str_lex == serialized can't fail here. 3.14159265358979 or 1.23456789012345E-5 breaks it (see the note on eval/value.rs). Worth one f32-inexact case whichever way the fix goes.

[aaj3f]

Confirmed exactly as you read it — with the fix reverted, the original three rows all stay green (they pass under either implementation) and only an inexact row discriminates. Added both of your candidates (3.14159265358979, 1.23456789012345E-5); red without the fix (left: "3.1415927E0" / right: "3.14159265358979E0"), green with it. Also added the same inexact value on the EncodedLit lane (sparql_encoded_xsd_float_str_matches_serializer, reindexed ledger, next to the #1470 re-tag tests) since the memory-ledger tests never touch that lane — and proved it actually fires by disabling only the encoded arm of stored_float_f64: the encoded test goes red with the same truncation while the Lit-lane test stays green.

[bplatz]

This builds a term's lexical form rather than a cast result, so canonical_xsd_float is arguably what belongs here: BIND(?f + 0 AS ?y) over a stored 1.0E0 float yields "1"^^xsd:float, so the same value spells two ways depending on provenance. STR() does agree with the serializer per-term, but on a non-canonical spelling — the class of thing #1445/#1695 exist to remove. Fine to keep deliberately; the comment should then say that.

[aaj3f]

Reproduced as described: stored "1.0E0"^^xsd:float serializes 1.0E0, BIND(?f + 0 AS ?y) yields "1"^^xsd:float. Two spellings by provenance, exactly.

I did try the switch before deciding, and it breaks something concrete: a minted float binding is a string-backed literal, and xsd:string(?y) reads that lexical verbatim (the TypedLiteral{String} fall-through in cast_to_string). Today that's "1" — which is what XPath requires for the cast, verified at head — so minting "1.0E0" instead makes the rebound cast wrong, and fixing that would mean teaching cast_to_string to parse float-typed strings back out, i.e. the split just moves. So: each minted term is internally consistent (serializer, STR(), and xsd:string() of it all return the one string), the split is between two terms rather than two renderings of one term — but you're right that the value-level split is the #1445/#1695 class. Kept deliberately, and the comment now says exactly that, with the rebound-cast reasoning inline. Cross-provenance canonicalization rides with the serializer-precision decision in #1776 — if we ever narrow the serializer to f32 by datatype, this arm collapses into it for free.

[bplatz]

On the range gap you flagged in the description: it's two-sided. xsd:string(1.0E-7) returns 0.0000001 where XPath wants 1.0E-7, same rule as the >= 1e6 side. Worth filing — mention both bounds.

[aaj3f]

Verified both bounds by execution at head: xsd:string(1.0E-7) → 0.0000001, xsd:string(1.0E30) → the 31-digit integer. Two-sided, as you said.

Folded rather than filed, though — the "implementing XPath's algorithm" cost I punted on in the description had quietly collapsed once canonical_xsd_double/canonical_xsd_float existed: outside [1e-6, 1e6) XPath prescribes the canonical lexical representation, which is precisely those writers, so the whole fix is a range check in format_f32/format_f64. Unit pins on the bounds (1e-6 inclusive stays decimal, 1e6 exclusive goes scientific, zero stays "0"), integration cast columns pin 1.0E-7/1.0E6/1.0E30, W3C still 36/0 — nothing in the corpus reaches either side. PR body updated to match.

[bplatz]

Nit: this arm ignores dtc, so a float arriving as TypedLiteral { val: Double, .. } takes the f64 branch while Float takes f32. Doesn't reproduce today (floats reach the cast as Float), but it's the same variant-vs-datatype conflation as the STR() issue.

[aaj3f]

Confirmed — and it's unreachable by construction, not just unreproduced: I went through every TypedLiteral producer, and none wraps a Double (STRDT/STRLANG/casts wrap strings, TryFrom<FlakeValue> maps Double to the bare variant, unwrap_typed_literal extracts it back out, the temporal family is the only non-string wrap). Execution agrees — both float shapes take other arms (stored → Float → 3.1415927, STRDT-minted → string-backed → verbatim). Left the arm as belt-and-braces and added the guarding comment naming the variant-vs-datatype conflation and pointing at #1776, so if a producer ever appears the arm's obligation to split on the datatype is written down where it'll be found.

[bplatz]

Nit: debug_assert!(d.is_finite()) went away with the generic, so the contract is doc-only now. Both public wrappers guard, so nothing is broken — a sealed trait, or an assert at the two call sites, restores the machine check.

[aaj3f]

Took the sealed-trait shape — it turned out to pay for itself twice: XsdFloat (private sealed module, f32/f64 only) hands finite_canonical its debug_assert! back, and it's the same trait the NaN/INF dedupe from your other note hangs off, so it isn't speculative machinery. Call-site asserts would've been vacuous here anyway — each wrapper branches on the specials one line above the call.

[bplatz]

Nit: the NaN/INF spelling is now written four times (here, canonical_xsd_double, format_f32, format_f64). One helper would do.

[aaj3f]

Done — XsdFloat::nonfinite_xsd(), a default method on the sealed trait returning Option<&'static str>, so the spelling exists exactly once and costs nothing. Wired through all four formatters here plus format_f32/format_f64 in eval/cast.rs — your four sites turned out to be six once I counted the push/write variants, all on the one helper now.