Subject: [Json] RFC 7386: correct indentation of the MergePatch function...

From: Francis Galiegue <[email-masked]>
Date: Thu, 30 Oct 2014 12:29:32 +0100

Hello,

[note: plain text message, please read with a fixed width font!]

In the RFC as well as in the errata, the MergePatch function suffers
indentation problems. Am I correct to surmise that this is the correct
indentation?

      define MergePatch(Target, Patch):
        if Patch is an Object:
          if Target is not an Object:
            Target = {} # Ignore the contents and set it to an empty Object
          for each Name/Value pair in Patch:
            if Value is null:
              if Name exists in Target:
                remove the Name/Value pair from Target
              else:
                Target[Name] = MergePatch(Target[Name], Value)
          return Target
       else:
         return Patch

-- 
Francis Galiegue, [email-masked], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/parboiled1/grappa (redde
Caesaris: https://github.com/sirthias)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 30 Oct 2014 12:37:13 +0100

>                Target[Name] = MergePatch(Target[Name], Value)

Unfortunately, not quite.

http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-07

says:

You can also look at

https://gist.github.com/cabo/7888768#file-merge-patch-rb

which is the same thing in a language that is not indentation-sensitive.

Grüße, Carsten

---

From: Francis Galiegue <[email-masked]>
Date: Thu, 30 Oct 2014 13:18:54 +0100

>            Target[Name] = MergePatch(Target[Name], Value)

Wee! Glad I asked, then... I'd have made a fundamental implementation mistake.

> which is the same thing in a language that is not indentation-sensitive.

Thanks for the pointer!

Regards,

---

From: Francis Galiegue <[email-masked]>
Date: Thu, 30 Oct 2014 13:39:56 +0100

[...]
>            Target[Name] = MergePatch(Target[Name], Value)

OK then, might I suggest that the pseudo-language used be independent
of the indentation? This could be another erratum, I guess, only I
don't even know how to "post" an erratum to begin with.

Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 30 Oct 2014 13:51:46 +0100

On 30 Oct 2014, at 13:39, Francis Galiegue <[email-masked]> wrote:
> I

You don’t have to — it’s already there:

http://www.rfc-editor.org/errata_search.php?rfc=7386

If you have a look at https://tools.ietf.org/html/rfc7386, you can see the red “Errata exist”, and the link “[Errata]” on top of that.  That leads to the errata known so far.

(We need to campaign for the tools.ietf.org interface to the RFCs some more; this is the only interface that alerts the reader to errata and/or new versions of RFCs.)

There isn’t necessarily a fundamental problem with indentation-dependence here; there just was an accident with a space-to-tab-to-space conversion on the way to the RFC, and because most of the tools we tend to use, ignore whitespace, nobody noticed until it was too late.

Grüße, Carsten

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 30 Oct 2014 16:22:42 +0100

On Thu, Oct 30, 2014 at 01:39:56PM +0100,
 Francis Galiegue <[email-masked]> wrote 
 a message of 39 lines which said:

> of the indentation? This could be another erratum, I guess,

No. The RFC editor insisted several times that the errata should be
for _errors_, not for disagreements. The working group decided to use
an indentation-dependant language, you may disagree but it is not an
error. Instead, you should engage with the working group to convince
it to switch. An Internet-Draft "Indentation-dependant languages for
pseudocode considered harmful" could be a start.

> only I don't even know how to "post" an erratum to begin with.

http://www.rfc-editor.org/errata.php

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 30 Oct 2014 16:24:39 +0100

On Thu, Oct 30, 2014 at 01:51:46PM +0100,
 Carsten Bormann <[email-masked]> wrote 

> http://www.rfc-editor.org/errata_search.php?rfc=7386

The current one (#4132) is about a specific error caused by
indentation. Francis wanted to report about the use of indentation
itself (see my previous message for why it would be a bad idea to use
the RFC errata system for that).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 30 Oct 2014 16:30:11 +0100

On Thu, Oct 30, 2014 at 12:29:32PM +0100,
 Francis Galiegue <[email-masked]> wrote 
 a message of 32 lines which said:

> indentation problems. 

The errata is in state Verified which means it has been checked and
found OK. If you spotted an error in it, you should report it with
more details.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Oct 2014 08:34:54 -0700

A few things here:

- The corrected RFC is on its way. You can see the temporary version at http://www.rfc-editor.org/authors/rfc7396.txt

- Carsten Bormann suggested using pseudocode instead of the original prose, and it got support.

- When I introduced the specific pseudocode to the draft, I think there were no objections, nor did I hear any suggestions for formats that could be clearer.

- I'm quite open to reissuing the RFC (again) with a different form of pseudocode. We now have a working example of where it can be misunderstood; what can we do better?

--Paul Hoffman

> On Oct 30, 2014, at 8:22 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

---

From: Francis Galiegue <[email-masked]>
Date: Thu, 30 Oct 2014 17:50:23 +0100

> - The corrected RFC is on its way. You can see the temporary version at http://www.rfc-editor.org/authors/rfc7396.txt

OK, I may have had my priorities messed up in the original mail, but
just one thing: "if" should be paired with "endif" in such pseudocode
at the very least.

In the current RFC, it isn't; and I am a seasoned programmer in
languages where indentation _does not_ matter (C, C++, Java, take your
pick) whereas the current wording in the RFC assumes seasoning in
languages were indetation _does_ (Python and Cobol for instance). What
does not help either is that indentation is done with only two spaces,
which is difficult to read. See Linux' Documentation/CodingStyle
(well, OK, I use 4, not 8, but I wouldn't even dare use 2).

So, those are two problems. While I have no ready-made solution right
now, I merely suggest that the pseudo code be made truly unambiguous,
either by changing the language or indenting it in a more "readable"
way.

So yes, there are problems remaining.