Re: [Json] Streaming JSON parsers

[Stefan Drees <[e-mail]>]

On 2013-07-03 05:01 +02:00, John Cowan wrote:
> I was asked in private mail if there actually were any streaming JSON
> parsers.  I googled for that phrase, and immediately found that
> <http://stackoverflow.com/questions/444380/is-there-a-streaming-api-for-json>
> mentions at least eight of them:  Jackson, Json-simple, Gson, YAJL,
> Clarinet, LitJSON, the JSON Streaming Parser for PHP, and Software
> Monkey's parser (the last two appear not to have names).  I have not
> verified this claim.
>
> It was suggested to me that list members may not be aware of this.
>

also while developing the version 4.0 Open Data specification at OASIS 
extra care is taken to ease the life for streaming JSON parsers, where 
the main notion for streaming there indicates at least stable ordering 
of names in objects and preferrably the semantically most useful 
ordering (for processing on the client side).

As OData defines a base protocol to deliver even high volume data 
(including navigateable metadata) this is important for most usage 
scenarios out in the wild.

The current second committee specification draft (going into public 
review this week) states eg. in section 2 "JSON Format Design"

"""
JSON, as described in [RFC4627], defines a text format for serializing 
structured data. Objects are serialized as an unordered collection of 
name-value pairs.

JSON does not define any semantics around the name/value pairs that make 
up an object, nor does it define an extensibility mechanism for adding 
control information to a payload.

OData’s JSON format extends JSON by defining general conventions for 
name-value pairs that annotate a JSON object, property or array. OData 
defines a set of canonical annotations for control information such as 
ids, types, and links, and custom annotations MAY be used to add 
domain-specific information to the payload.

[...]

To optimize streaming scenarios, there are a few restrictions that MAY 
be imposed on the sequence in which name/value pairs appear within JSON 
objects.
"""

And esp. in section 4.4 "Payload Ordering Constraints" this:
"""
Ordering constraints MAY be imposed on the JSON payload in order to 
support streaming scenarios. These ordering constraints MUST only be 
assumed if explicitly specified as some clients (and services) might not 
be able to control, or might not care about, the order of the JSON 
properties in the payload.

Clients can request that a JSON response conform to these ordering 
constraints by specifying a media type of application/json with the 
odata.streaming=true parameter in the Accept header or $format query 
option. Services MUST return 406 Not Acceptable if the client only 
requests streaming and the service does not support it.

Processors MUST only assume streaming support if it is explicitly 
indicated in the Content-Type header via the odata.streaming=true 
parameter.

   Example 3: a payload with

   Content-Type: 
application/json;odata.metadata=minimal;odata.streaming=true

   can be assumed to support streaming, whereas a payload with

   Content-Type: application/json;odata.metadata=minimal
   cannot be assumed to support streaming.

JSON producers are encouraged to follow the payload ordering constraints 
whenever possible (and include the odata.streaming=true content type 
parameter) to support the maximum set of client scenarios.

To support streaming scenarios the following payload ordering 
constraints have to be met:

* If present, the odata.context annotation MUST be the first property in 
the JSON object.

* The odata.type annotation, if present, MUST appear next in the JSON 
object.

* The odata.id and odata.etag annotations MUST appear before any 
property or property annotation.

* All annotations for a structural or navigation property MUST appear as 
a group immediately before the property they annotate. The one exception 
is the odata.nextlink annotation of an expanded collection which MAY 
appear after the navigation property it annotates.

* All other odata annotations can appear anywhere in the payload as long 
as they do not violate any of the above rules.

* Annotations for navigation properties MUST appear after all structural 
properties.
"""

URL: 
https://www.oasis-open.org/committees/document.php?document_id=49674&wg_abbrev=odata

I cited quite greedily because the URL points to a zip file containing a 
document in the OfficeXML format, which might not be the most directly 
accessible format for everyone on the list wanting to just skim through.

{"Stefan":true}