Re: [Json] serializing sequences of JSON values

Tatu Saloranta <> Fri, 14 March 2014 04:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3E4861A0007 for <>; Thu, 13 Mar 2014 21:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H3UCfAAN1wL8 for <>; Thu, 13 Mar 2014 21:04:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) by (Postfix) with ESMTP id DE98A1A0005 for <>; Thu, 13 Mar 2014 21:04:10 -0700 (PDT)
Received: by with SMTP id cc10so4809162wib.2 for <>; Thu, 13 Mar 2014 21:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q7SwYaiuL8dpMl6+BnNA7hwsV3hPVnoG4VEjpzYGc4M=; b=uEoV8VY1aV05K2eHa3j9GGj0fm67iBZKNAEeEw9uHPWizdkYQSg6lGBpQsxlX3Jtdf TTP+YBk3RkMxDJJMIduYTIurmo4Ry1PFLrIqVcaraQUNhBgqfQ/vNDSVAaBOERY8JF30 XuwDbgz6VCFr0KEEm5PgoFxRS3mgDG5aHbS8Igen4oTKRxkdkrsYUPksYSVGgiJomXEK CuLQXhHwFaSyQ86AQ77q63YehIGu2swwLAyBxtzQ7j6zUIZECKVUt0bD4Uzd56LDb+Fj EFf3+cOSKF2JoUZZw5Sf2aDsBncEysm8PQwrRcF/335Tx/pBswzyc9t5kyf6vgAW/mfU DNtg==
MIME-Version: 1.0
X-Received: by with SMTP id ff8mr4261810wic.25.1394769843797; Thu, 13 Mar 2014 21:04:03 -0700 (PDT)
Received: by with HTTP; Thu, 13 Mar 2014 21:04:03 -0700 (PDT)
In-Reply-To: <>
References: <em2c025504-6532-4513-a339-3d71c4cdfbda@helsinki> <> <> <> <>
Date: Fri, 14 Mar 2014 04:04:03 +0000
Message-ID: <>
From: Tatu Saloranta <>
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= <>
Content-Type: multipart/alternative; boundary=001a11c364ba15459704f489298d
Cc: "" <>, Matt Miller <>
Subject: Re: [Json] serializing sequences of JSON values
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Mar 2014 04:04:13 -0000

On Fri, Mar 14, 2014 at 3:02 AM, "Martin J. Dürst"

> Hello Matt,
> On 2014/03/14 07:23, Matt Miller wrote:
>> Hash: SHA512
>> On 3/13/14, 3:23 PM, Larry Masinter wrote:
>>> I wonder if there is any lesson from XMPP--  which wanted
>>> sequence-of-XML-values in an indefinite length stream -- that would
>>> apply to JSON. What would XMPP look like if it were redone in JSON
>>> instead of XML?
>> /me exchanges JSON chair hat for XMPP enthusiast hat ...
>> If XMPP didn't exist and we instead did JMPP, it might be a series of
>> discrete objects.  However, the direction of the later "XMPP over <x>"
>> adaptations (e.g., [BOSH] and [XMPP-WS]) speak toward wanting to use
>> an existing transport that provides block-oriented framing around
>> complete structures.
>> Dealing with partial XML-like structures in XMPP has ranged from
>> inconvenient to impractical because the vast majority of existing XML
>> software has assumed a whole XML document when parsing starts.  There
>> are few libraries that truly allow one to feed XML in fits and starts
>> and get timely output without some amount of modification or
>> preprocessing.  When the XMPP community took efforts to apply XMPP
>> over other transports, the direction has so far leaned toward the
>> whole documents that most implementations expect; even though the
>> preprocessing required is rather small, the ability to re-use existing
>> implementations without first considering oft-unpublished details was
>> a very powerful motivator.
> This is very valuable feedback.
> As far as I understand, the problem for XMPP has at least two parts:
> 1) The XML document arrives in pieces.
> 2) Parsing is done in pieces
> My understanding is that parsing in pieces is well covered by SAX parsers,
> so that the problems essentially came from 1). But problem 1) doesn't apply
> to JSON text sequences exchanged as MIME types, and it doesn't apply to log
> files as these are rarely read, and when read, that could just be done with
> something like
> > echo ']' > json-array-close.txt
> > cat logfile.json json-array-close.txt | json-parse
> (using [pseudo-]shell syntax).
> As for delayed exchange of multiple JSON texts, e.g. a (completely
> hypothetical) JMPP (JSON Messaging and Presence Protocol), one would try to
> use a message-oriented transport (e.g. WebSockets) and then not need a
> concept of JSON text sequences at all.
Major challenge with sequence of XML documents is really just implementors,
and inertia.
Having written a fully conformat XML parser that optionally supports
"fragment mode" (Woodstox for Java; implements SAX and Stax APIs) I can say
that compared to all other work, supporting multiple root-level documents
is a minor addition. Mode is used/useful for supporting XMPP, as well as
for use for streaming logging, similar to what has been discussed for JSON.
It has to be explicitly enabled (since such usage is non-compliant, having
multiple roots).

There are some minor details (like xml declaration, what to do if it is
repeated) to deal with,
to allow simple concatenation, but all in all it is not a big technical
problem. I mean, compared to writing actual fully compliant parser
(supporting DTD is 80+% of the deal).

-+ Tatu +-

> Regards,   Martin.
> _______________________________________________
> json mailing list