Re: [Json] Description of parsers

Stefan Drees <stefan@drees.name> Mon, 10 June 2013 11:56 UTC

Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50AE21F8F29 for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 04:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUTrWbr5+ZB6 for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 04:56:16 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id A8CD821F8647 for <json@ietf.org>; Mon, 10 Jun 2013 04:56:13 -0700 (PDT)
Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0M4lkz-1UQjp92N6T-00yz5Q; Mon, 10 Jun 2013 13:56:11 +0200
Message-ID: <51B5BED9.3030308@drees.name>
Date: Mon, 10 Jun 2013 13:56:09 +0200
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <20130609042518.11918.qmail@joyce.lan> <51B44197.2000006@drees.name> <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org> <2014F29A-4F38-4E8C-A05C-892F9B06A7E2@tzi.org>
In-Reply-To: <2014F29A-4F38-4E8C-A05C-892F9B06A7E2@tzi.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:YLPfFOPn0OEJX2GqXnygCphnRzvBbckkI7kJpfTFqMk+UcW163W 21btAl3u0izZxtaFZhVGomr0WpbXXh/JNwslHN1hKp6NPG3tqVs3x9ZRNubpdSxGMmIvEN6 X3TJAnt+9RzvehCxeksTzMseXiaPU4uzhx+VMIrH2wwy+xPsw1LKElv/1dtUe7Z6MQm5Jdi l8zpBjgx1wZ01Jf1xx58Q==
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Description of parsers
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 11:56:22 -0000

On 2013-06-10 12:27 CEST, Carsten Bormann wrote:
> On Jun 9, 2013, at 22:38, Paul Hoffman ... wrote:
>
>>> duplicate names in objects
>
> That doesn't mean anything, until it has been defined.

I think here the contxt is confined to parsers and is a summarizing 
description with focus on the parsers. I understand the job of the 
section 2 to introduce the vocabulary. So the name is the first part of 
the ordered pair (name, value).

>
> Is "foofoo" a duplicate name?

not in itself, but maybe if some other "foofoo" in the same object and 
nesting level comes along or preceeded it.

>
> Or is it just not allowed to write
> { "foo" "foo" : "bar" }
> ?

here the parser is already out, as this is invalid JSON.


> Or is it that all maps (objects) must have unique names, so
> [{"foo": "bar"}, {"foo": "baz"}]
> is an instance of a duplicate name?

we should talk about names of a single object and nesting level.
So no.

> Or maybe this is about the names within an object, so
> {"foo": {"foo": "bar"}}
> is an instance of a duplicate name?

No. ditto.

> ->
> Of the name/value pairs that comprise a single object, no two
> [shall/should/whatever] have the same name.
> For the purposes of this comparison, two names are the same if they
> are the same sequence of characters after processing the strings (2.5).


As long as we do not "invent" something, but are all sure, that the 
"common" knowledge where it fills a real gap has also been "shared by 
all known implementers" knowledge :-) ...

> [RFC 4627 doesn't quite define what that is, either, but one can
> complete section 2.5 with common knowledge such as that the quotes
> aren't meant to be part of the decoded string.] ...

How do the existing validators and parsers decide that {"a" "a":"b"}
is invalid maybe the ABNF rules :-?)
"""
          object = begin-object [ member *( value-separator member ) ]
                 end-object
          member = string name-separator value
[...]
          string = quotation-mark *char quotation-mark
          char = unescaped /
                 escape (
                     %x22 /          ; "    quotation mark  U+0022
                     %x5C /          ; \    reverse solidus U+005C
                     %x2F /          ; /    solidus         U+002F
                     %x62 /          ; b    backspace       U+0008
                     %x66 /          ; f    form feed       U+000C
                     %x6E /          ; n    line feed       U+000A
                     %x72 /          ; r    carriage return U+000D
                     %x74 /          ; t    tab             U+0009
                     %x75 4HEXDIG )  ; uXXXX                U+XXXX

          escape = %x5C              ; \

          quotation-mark = %x22      ; "

          unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

"""
where
     "a" "a"
seems not to match the rule for a string in rule member.

All the best,

Stefan.