id equality
Joe Walker
According to http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal
and id handling: "The server MUST repeat it verbatim on the Response."
Does this imply that a client that sends a request with "id:2.0" can
expect that the response will not be "id:2"?
I suspect that allowing clients to differentiate between these types
of input will make servers unnecessarily complex, and that clients
should only expect that the server will send a response that is === to
the request.
Joe.
Skylos
Lazily not going to see,
Skylos
Roland Koebler
> According to http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal
> and id handling: "The server MUST repeat it verbatim on the Response."
>
> Does this imply that a client that sends a request with "id:2.0" can
> expect that the response will not be "id:2"?
that depends on what you mean by writing "id:2", since "id:2" is not
valid json:
- "id":2.0 and "id":2
here, the "id"-field has a *numeric* value of 2 (or 2.0), and the two
values are completely identical, according to the json-specification
(see http://www.json.org).
how this numeric value is represented in json-text probably depends
on the used json-serializer, and you should not rely on a specific
form. although probably many json-serializers would re-serialize
2.0 to 2.0, things like 2, 2E0 or 0.0002e4 would also be valid.
- "id":"2.0" and "id":"2"
here, the "id"-fields are *strings*, and the two string-values are
of course different. and the server must response with the string-value
it received.
> I suspect that allowing clients to differentiate between these types
> of input will make servers unnecessarily complex, and that clients
> should only expect that the server will send a response that is === to
> the request.
json-rpc works on top of json, so it is important which *values* are stored
in json; but it doesn't matter *how* they are stored.
but note that I would recommend not to use numbers with fractional parts
for "id", since testing for equality is problematic for floating point
values. (see e.g. http://en.wikipedia.org/wiki/Machine_epsilon)
regards,
Roland
Kris Zyp
> - "id":2.0 and "id":2
> here, the "id"-field has a *numeric* value of 2 (or 2.0), and the two
> values are completely identical, according to the json-specification
> (see http://www.json.org).
> how this numeric value is represented in json-text probably depends
> on the used json-serializer, and you should not rely on a specific
> form. although probably many json-serializers would re-serialize
> 2.0 to 2.0, things like 2, 2E0 or 0.0002e4 would also be valid.
>
>
where on http://www.json.org there is the definition of numerical
equality. It makes sense that 2 are treated and 2.0 are treated as
identical JSON values, just wanted to know where that is spelled out (it
is conceivable that a language could maintain the "form" of a number,
and treat these as unequal. Future versions of EcmaScript may have
decimal support and a JSON parser could choose to convert 2.0 to decimal
and 2 to binary with possible === -> false results, not sure where the
spec is at right now on that).
Kris
Joe Walker
On Nov 13, 5:19 pm, Kris Zyp <kris...@gmail.com> wrote:
> > - "id":2.0 and "id":2
> > here, the "id"-field has a *numeric* value of 2 (or 2.0), and the two
> > values are completely identical, according to the json-specification
> > on the used json-serializer, and you should not rely on a specific
> > form. although probably many json-serializers would re-serialize
> > 2.0 to 2.0, things like 2, 2E0 or 0.0002e4 would also be valid.
>
> I am sure that this is what Joe was asking about.
"id":2.0.
I would guess that any other reading could make life very hard for
many implementations for little gain.
Perhaps the language "The server MUST repeat it verbatim on the
Response" could be clearer.
Maybe it should read: "The server MUST reply with an equal id on the
Response, where equal is defined by the JavaScript operator ===".
> However, I am curious
> where onhttp://www.json.orgthere is the definition of numerical
> identical JSON values, just wanted to know where that is spelled out (it
> is conceivable that a language could maintain the "form" of a number,
> and treat these as unequal. Future versions of EcmaScript may have
> decimal support and a JSON parser could choose to convert 2.0 to decimal
> and 2 to binary with possible === -> false results, not sure where the
> spec is at right now on that).
consensus was that it was too hard for 3.1, but I've not been
following it too hard.
Joe.
Matt (MPCM)
> "id":2.0.
> I would guess that any other reading could make life very hard for
> many implementations for little gain.
and json handling of numbers.
Both sides need to honor what the JSON format intends, not what base
language understands it as. This does make it slightly less obvious
for implementers, but if the base language has a difference of
representation to/from JSON, the correct matching up of a response is
not on the native object id of the request, but instead on the json'd
value of that id against the json'd value of the response object id.
Those might be the same, but == and === could come into play in ways
which are different on both the client and the server, and JSON is the
middle ground.
Personally I use randomized non-sequential strings...
--
Matt (MPCM)
Stephen McKamey
and leave it to the IEEE specification to determine equality?
If your application must have "2.0" then use a string. The other
works great as an index into an array of current calls, but indexers
wouldn't care about the precision.
Roland Koebler
> However, I am curious
> where on http://www.json.org there is the definition of numerical
> equality. It makes sense that 2 are treated and 2.0 are treated as
> identical JSON values, just wanted to know where that is spelled out
it isn't said explicitly on json.org. but json has only 1 "numeric"
type, and does not differentiate between e.g. integers and floats.
and since json allows different "representations" of the same value,
these representation of course must be equivalent -- everything else
would be futile.
> (it is conceivable that a language could maintain the "form" of a number,
> and treat these as unequal.
a language may of course maintain the "form" of a number, but it may *not*
rely on a specific number-format in json.
> Future versions of EcmaScript may have
> decimal support and a JSON parser could choose to convert 2.0 to decimal
> and 2 to binary with possible === -> false results, not sure where the
> spec is at right now on that).
then you (a) shouldn't use "===" for the comparison or (b) assert that
the variables are of the expected type.
regards,
Roland
Roland Koebler
> I think we're agreed that "id":2 is a valid response to a request of
> "id":2.0.
yes.
> Perhaps the language "The server MUST repeat it verbatim on the
> Response" could be clearer.
yes, you're right. what do you think of:
"The server MUST reply with the same value it received."
that should be clearer.
> Maybe it should read: "The server MUST reply with an equal id on the
> Response, where equal is defined by the JavaScript operator ===".
No, that would be (a) very bad and (b) impossible.
a) JSON is language-independent, and the JSON-RPC-specification should
not refer to a specific language, or a specific function in a language.
b) That even wouldn't be possible, without breaking the JSON-specification.
(Since JSON has a restricted set of types, and there is no bijective
relation between JSON types and the types of all programming languages. ;))
regards,
Roland