[netmod] RFC7952 JSON streaming decoding efficiency?

Robert Varga <nite@hq.sk> Wed, 27 February 2019 22:26 UTC

Return-Path: <nite@hq.sk>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A4B61131176 for <netmod@ietfa.amsl.com>; Wed, 27 Feb 2019 14:26:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id c53Dq0ZF61Ye for <netmod@ietfa.amsl.com>; Wed, 27 Feb 2019 14:26:36 -0800 (PST)
Received: from mail.hq.sk (hq.sk []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD03131175 for <netmod@ietf.org>; Wed, 27 Feb 2019 14:26:36 -0800 (PST)
Received: from nitebug.nitenet.local (chello085216197060.chello.sk []) by mail.hq.sk (Postfix) with ESMTPSA id D8D7B242003 for <netmod@ietf.org>; Wed, 27 Feb 2019 23:26:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1551306393; bh=yYuoO7xaHMYbp80Wr8ADkDS4wzxtvm1uVYwFUWjBxO4=; h=To:From:Subject:Date; b=XE5tAxlzuMGZwYHkqjN6s2umiLOv//BBL1qZdByi7EUB7/FYuxvy0PXqnag9LsZD2 TgK0sy9ZSWS41Fea2dgzG5eTaBFX7WLuDKhu65cxLGpDHRQwtlbR8QV+7+/NgHncAR T2TN9E9BoZVCWkLNEVpJdJujKN3mhmAstzPIQp1o=
To: "netmod@ietf.org" <netmod@ietf.org>
From: Robert Varga <nite@hq.sk>
Openpgp: preference=signencrypt
Message-ID: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk>
Date: Wed, 27 Feb 2019 23:26:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w8UhVh3W0mV45qlpkkFzDIkfIWEvuKsCN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/h8lLpVy3aYjJA7yGdjOGZUsn-xQ>
Subject: [netmod] RFC7952 JSON streaming decoding efficiency?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 22:26:38 -0000


reading RFC7952 sections 5.2.2-5.2.4, it would seem that metadata object
(5.2.2) can occur at any position in a JSON object, as well as metadata
attachments to leaf/leaf-list/anyxml (5.2.3, 5.2.4) can occur any
distance (before or after) from the data element they attach to.

The examples list the metadata object as the first item, and attachments
immediately after the data element, but I could find no text which would
make this required or recommended for document producers.

While this is completely workable when the parsing state is received
into a mutable structure, it requires full parser event buffering in
streaming setups.

One example would be JSON->XML transformation using token streaming
interfaces (like GSON's JsonReader and
javax.xml.stream.XMLStreamWriter): since metadata can occur at any place
in JSON, but is required to be emitted just after opening XML element,
we must completely parse the JSON document before we can start emitting
the XML document.

Is this intentional or just an omission?