Subject: [apps-discuss] JSON-Patch: testing objects [#11]

From: Mark Nottingham <[email-masked]>
Date: Sat, 11 Aug 2012 17:21:30 -0500

I've checked in some text that tries to address #11, and ended clarifying other parts about how "test" works.

Proposed text:

---8<---
4.6.  test

   The "test" operation tests that a value at the specified location in
   the target document is equal to a specified value.  The operation
   object contains a "value" member that specifies the value to test
   for.

   Here, "equal" means that the target and specified values are compared
   using the following rules:

   o  strings: are considered equal if, after unescaping any sequence(s)
      in either string starting with a reverse solidus, they contain the
      same number of Unicode characters and their code points are
      position-wise equal.

   o  numbers: are considered equal if they subtracting one from the
      other results in 0.

   o  arrays: are considered equal if they contain the same number of
      values, and each value can be considered equal to the value at the
      corresponding position in the other array.

   o  objects: are considered equal if they contain the same number of
      members, and each member can be considered equal to a member in
      the other object.  Note that ordering of the serialisation of
      object members is not significant.

   o  literals (false, true and null): are considered equal if they are
      the same.

   Note that this is a logical comparison; e.g., whitespace between the
   member values of an array is not significant.
--->8---

This is obviously going to need some examples (particularly around comparing numbers and strings, I think), but I wanted to make sure people were OK with this direction first.

In particular, does escaping strings before comparison make sense? And, is the technique for comparing numbers adequate?

Regards,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 14 Aug 2012 11:28:25 -0700

>    using the following rules:

Possibly point-out that both values must have the same type in order to
evaluate to equal? In other words, 0 the number and "0" the string are
not equal.

>       same number of Unicode characters and their code points are

s/either/both/. Logically makes sense.

>    o  numbers: are considered equal if they subtracting one from the

s/they //. Logically, makes sense.

>       object members is not significant.

I would point out that member equality means that the key == key
(string) and value == value (both values must be of same type and
evaluate equally per this section).

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 15 Aug 2012 21:17:43 -0700

Thanks, all looks reasonable; will update.

On 14/08/2012, at 11:28 AM, Paul C. Bryan <[email-masked]> wrote:

> Possibly point-out that both values must have the same type in order to evaluate to equal? In other words, 0 the number and "0" the string are not equal.
> 
> I would point out that member equality means that the key == key (string) and value == value (both values must be of same type and evaluate equally per this section).
> 
>> 

--
Mark Nottingham
http://www.mnot.net/