Should we consider `-0` as special number?

[nvborisenko]

webdriver-bidi/index.bs

Line 8485 in 3a04347

script.SpecialNumber = "NaN" / "-0" / "Infinity" / "-Infinity";

-0 is valid number in json. If BiDi requires it to be String, then consumers will write extra code to serialize/deserialize this "-0" special case. If -0 would be a normal number, then serialization/deserialization properly handles it out of the box, including NaN, Infinity and -Infinity.

Note: Firefox properly handles both -0 and "-0", Chromium works only with "-0" and doesn't allow -0.

[jgraham]

FWIW the Python default JSON library interprets "-0" as 0, but "-0.0" as -0. That might be a bug, but given there's an interop footgun here, and one already needs to handle various special cases, I'm inclined to leave the spec as-is.

[gsnedders]

If -0 would be a normal number, then serialization/deserialization properly handles it out of the box, including NaN, Infinity and -Infinity.

That depends on the JSON library; plenty of JSON libraries in plenty of languages don't handle NaNs or infinities — because they're unrepresentable in JSON — and will raise an error if they occur.

I'm curious about why we believe -0 is worthwhile special-casing; we don't in WebDriver Classic, after all.

[nvborisenko]

UP

Break earlier or never...

[jgraham]

I'm curious about why we believe -0 is worthwhile special-casing; we don't in WebDriver Classic, after all.

Worth special casing relative to what? As a number it is a special case; it looks like an integer, and it's (mathematically) in-range for signed integers, but can't be represented by an integer type in most languages. Hence the Python issue above, which is presumably because the JSON parser only converts the output to a float if it finds a . in the input.

So, from a spec point of view, the reasoning is:

• This avoids some known bugs, allowing -0 to be unambiguously serialized at the cost of a small amount of extra code in clients.
• It follows the precedent set by CDP, which suggests that the small amount of extra code is not an undue burden.

Comparing to WebDriver Classic seems like a bad idea; classic's serialization is full of problems, which is why we did something quite different for BiDi.

[jgraham]

My strong inclination is to close this as "Not Planned". Even if you don't agree with the reasoning above, I don't think it's worth introducing a breaking change at this point.

If there's any strong disagreement with that, it needs to be nominated for WG discussions.

[nvborisenko]

I can say only about .NET/C#. What I understand -0 is a special number for clients (in .NET it is double.NegativeZero). The same for -Infinity, it is double.NegativeInfinity. My concern is only about transport layer: why this number is transferred as string?

using System.Text.Json;
using System.Text.Json.Serialization;

// This is how .NET/C# understands "special" cases for integer/double
var negativeZeroAsNumber = "-0";

Console.WriteLine(JsonSerializer.Deserialize<int>(negativeZeroAsNumber));

Console.WriteLine(JsonSerializer.Deserialize<int>(negativeZeroAsNumber, new JsonSerializerOptions { NumberHandling = JsonNumberHandling.AllowNamedFloatingPointLiterals }));

Console.WriteLine(JsonSerializer.Deserialize<double>(negativeZeroAsNumber));

Console.WriteLine(JsonSerializer.Deserialize<double>(negativeZeroAsNumber, new JsonSerializerOptions { NumberHandling = JsonNumberHandling.AllowNamedFloatingPointLiterals }));

// This is how .NET/C# doesn't understand string representation of special json number
var negativeZeroAsString = "\"-0\"";

//Console.WriteLine(JsonSerializer.Deserialize<int>(negativeZeroAsString)); // throws The JSON value could not be converted to System.Int32

//Console.WriteLine(JsonSerializer.Deserialize<int>(negativeZeroAsString, new JsonSerializerOptions { NumberHandling = JsonNumberHandling.AllowNamedFloatingPointLiterals })); // throws The JSON value could not be converted to System.Int32

//Console.WriteLine(JsonSerializer.Deserialize<double>(negativeZeroAsString)); // The JSON value could not be converted to System.Double

//Console.WriteLine(JsonSerializer.Deserialize<double>(negativeZeroAsString, new JsonSerializerOptions { NumberHandling = JsonNumberHandling.AllowNamedFloatingPointLiterals })); // The JSON value could not be converted to System.Double

0
0
-0
-0

So "-0" is not respected at all. The cost to support it: SeleniumHQ/selenium@50abe67

I feel from specification point of view we may say to use double type instead of integer?

UPD: Oh no, just remove "-0" as special case, and transfer it as number -0.

[gsnedders]

I feel from specification point of view we may say to use double type instead of integer?

What do you mean, here? Is your proposal here to change:

script.NumberValue = {
  type: "number",
  value: number / script.SpecialNumber
}

To:

script.NumberValue = {
  type: "number",
  value: float64 / script.SpecialNumber
}

Because on the face of it that seems like a sensible change — the Number value in ECMAScript represents a float64, and when we're using CDDL to describe JSON I don't see why we'd use number and also allow arbitrary integers there?

But that still doesn't change the fundamental point of this issue, because our CDDL merely defines what is a valid JSON message, which has a singular number type.

UPD: Oh no, just remove "-0" as special case, and transfer it as number -0.

The problem with this is in many languages you then cannot use the JSON parser in the standard library, or some other very common JSON parser, because you get the wrong output — and you can't post-process 0 into -0.0f.

With node.js, for example, with the built-in JSON object, you have no way to do this.

The question is really "do we care about such JSON implementations?".

Certainly I'd assume the Selenium project would, because otherwise the JS implementation would need to migrate to a new JSON library.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Negative zero serialization.

The full IRC log of that discussion

<AutomatedTester> topic: Negative zero serialization
<AutomatedTester> github: https://github.com//issues/887
<AutomatedTester> jgraham: there was an issue. raised where someone raised -0. we currently do this a special representation as a string but JSON can do this natively
<AutomatedTester> ... first question: is there a strong case for changing this? I feel its highly risky with little reward.
<AutomatedTester> q?
<orkon> q+
<AutomatedTester> ack orkon
<AutomatedTester> orkon: I don't know enough about client libraries. it's not been an issue with our client. I think we should leave it as is as the case isn't strong enough
<AutomatedTester> q?
<AutomatedTester> jgraham: if people have any strong opinions please add further comments to the issue
<AutomatedTester> ... then the 2nd issue that gsnedders pointed out. We are currently using it as Number and it should probably be Float64. I am going to look into using JSInt or Float64. Does anyone have concerns?
<AutomatedTester> q?
<orkon> q+
<AutomatedTester> ack orkon
<AutomatedTester> orkon: I recall that CDDL spec has rules around JSON compatible. I think we should be using what the spec suggest as we use what is there
<orkon> present-
<jgraham> RSSAgent: make minutes
<jgraham> zakim, bye
<Zakim> leaving. As of this point the attendees have been jgraham, tidoust, orkon, whimboo, AutomatedTester, jdescottes, benchatt, jimevans

[nvborisenko]

I don't think that BiDi specification should be driven by json implementations in different languages. json supports -0 as number. Now it is a problem of specific language how to serialize it properly. I don't like that number is transferred as string, let's be more precise. It is number or string...

Everybody here says that "-0" is more convenient for serializers. I propose to test it, for every language.

[nvborisenko]

.NET

Using System.Text.Json serializer -0 is not special case, literally meaning it is just a normal number. Supporting of "NaN"/"Infitity"/"-Infinity" is built-in via AllowNamedFloatingPointLiterals flag - http://learn.microsoft.com/en-us/dotnet/api/system.text.json.serialization.jsonnumberhandling?view=net-9.0#system-text-json-serialization-jsonnumberhandling-allownamedfloatingpointliterals

The "NaN", "Infinity", and "-Infinity" String tokens can be read as floating-point constants, and the Single and Double values for these constants will be written as their corresponding JSON string representations.

.NET considers "NaN"/"Infitity"/"-Infinity" only values as special cases for numbers.

[jgraham]

In the WG meeting there was no sense that a change here would be worthwhile. As such I'm going to close the issue.

The point that @gsnedders brought up about the CDDL type used for the value attribute being over-broad considering the input is a JS number is valid; we should probably change that to js-int / float64.

Regarding the argument that it's an JSON implementation problem if they don't correctly support -0, I refer you to the TAG Web Platform Design Principles, in particular the section in Principle 1.1 "Put user needs first (Priority of Constituencies)" that says:

User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.

Doing something that technically ought to work, but in practice is known to break in many cases would be the exact opposite of what's required by the principle. The current design requires some implementors to do a small amount of extra work, but in doing so protects users from data loss in the face of a known issue with JSON implementations. Taking the theoretically pure approach would save a few implementors a small amount of work, but require other implementors to do a large amount of work (finding — or writing — a JSON implementation that handles this case correctly) and so, in practice, is likely to lead to buggy implementations that affect users.