{
    "judul" : "DOD keren",
    "type" : "Artikel",
    "isi" : "ini tentang DOD blablabla blabalablbal",
    "tanggal" : "2011/02/08"},
    "komentar" : {
       [
         {
           "isi": "artikelnya keren gan",
           "komentator": "M Kusnaeni"
         },
        {
          "isi": "tulisan apaan nih, jelek banget".
          "komentator" : "Nurdin Halid"
       },
       {
         "isi" : "no comment boss ah",
         "komentator" : "Mr Plin plan"
      } ,
    "tag" : [
       "Document Oriented Database",
       "NoSql",
       "CouchDB",
     ]
    }
where the error of my code?


[Non-text portions of this message have been removed]

--- In json@yahoogroups.com, "zaqi" <slash_jak@...> wrote:

> where the error of my code?

Try http://jslint.com/

On Sat, Nov 12, 2011 at 10:23 AM, zaqi <slash_jak@...> wrote:

> **
>
> {
> "judul" : "DOD keren",
> "type" : "Artikel",
> "isi" : "ini tentang DOD blablabla blabalablbal",
> "tanggal" : "2011/02/08"},
>

Your JSON root object ends at the '}' character after the date, but
contains trailing data.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/


[Non-text portions of this message have been removed]

On 12-Nov-2011 2:53 PM, "zaqi" <slash_jak@...> wrote:

> **
>
>
> {
> "judul" : "DOD keren",
> "type" : "Artikel",
> "isi" : "ini tentang DOD blablabla blabalablbal",
> "tanggal" : "2011/02/08"},
> "komentar" : {
> [
> {
> "isi": "artikelnya keren gan",
> "komentator": "M Kusnaeni"
> },
> {
> "isi": "tulisan apaan nih, jelek banget".
> "komentator" : "Nurdin Halid"
> },
> {
> "isi" : "no comment boss ah",
> "komentator" : "Mr Plin plan"
> } ,
> "tag" : [
> "Document Oriented Database",
> "NoSql",
> "CouchDB",
> ]
> }
> where the error of my code?
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

How to define table with json like MySQL?

On Fri, Nov 18, 2011 at 11:28 AM, zaqi <slash_jak@...> wrote:

> **
>
> How to define table with json like MySQL?
>
???

You appear to be misunderstanding what JSON is. It is a generic data
representation, not a language per se. It has no "tables" and no
relationship with any sort of database. Though there are databases which
support it or are even based on it, such relationships are one-way streets
- they have a relationship with JSON but JSON has no relationship with them.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/


[Non-text portions of this message have been removed]

Dear all,

Recently I released an open-source (MIT license) project, rapidjson, a C++ JSON
parser/generator with both SAX/DOM-style API.

http://code.google.com/p/rapidjson/

It is inspired by rapidxml, for its lightweight (rapidjson's SAX API only needs
few hundred lines of code), and high performance.

In my performance benchmark

http://code.google.com/p/rapidjson/wiki/Performance

the particular test case shows that rapidjson is faster than YAJL and JsonCpp,
and the parsing speed is in the order of magnitude of strlen().

I am actually new to JSON, and I did not heavily use of it in my projects.  I
really want to gather opinions. I have some immediate questions:

1. Is there any JSON dataset suitable for performance comparison?
2. Which JSON parsrs/generators are fast?
3. I tried to make rapidjson RFC4327 full-compliance. I have tested it with
jsonchecker's test suite. Is there any other test suites for proving a parser's
correctness?
4. Apart from RFC4627, is there any other add-on features which are important to
support?

Besides, I will try to provide more documentation (user guide, design, memory
benchmarks, etc.) soon.

Thank you for your attention.

Best regards,

Milo Yip.

Milo,

The benchmark numbers rapidjson is posting look fantastic. Nice job!

--- In json@yahoogroups.com, "MiloYip" <miloyip@...> wrote:
>
> Dear all,
>
> Recently I released an open-source (MIT license) project, rapidjson, a C++
JSON parser/generator with both SAX/DOM-style API.
>
> http://code.google.com/p/rapidjson/
>
> It is inspired by rapidxml, for its lightweight (rapidjson's SAX API only
needs few hundred lines of code), and high performance.
>
> In my performance benchmark
>
> http://code.google.com/p/rapidjson/wiki/Performance
>
> the particular test case shows that rapidjson is faster than YAJL and JsonCpp,
and the parsing speed is in the order of magnitude of strlen().
>
> I am actually new to JSON, and I did not heavily use of it in my projects.  I
really want to gather opinions. I have some immediate questions:
>
> 1. Is there any JSON dataset suitable for performance comparison?
> 2. Which JSON parsrs/generators are fast?
> 3. I tried to make rapidjson RFC4327 full-compliance. I have tested it with
jsonchecker's test suite. Is there any other test suites for proving a parser's
correctness?
> 4. Apart from RFC4627, is there any other add-on features which are important
to support?
>
> Besides, I will try to provide more documentation (user guide, design, memory
benchmarks, etc.) soon.
>
> Thank you for your attention.
>
> Best regards,
>
> Milo Yip.
>

Hi
My project UltraJSON (BSD license) could serve as the JSON encoder/decoder
back-end for this if you're going for absolute performance. AFAIK there
isn't anything faster out there.

Have look at https://github.com/esnme/ultrajson

The interface for encoder and decoder are structs of function pointers
which can be bound to any language. The current integration is how ever
made in CPython

But then again, maybe we're in competition :)

Cheers
//JT



2011/11/19 MiloYip <miloyip@...>

> **
>
>
> Dear all,
>
> Recently I released an open-source (MIT license) project, rapidjson, a C++
> JSON parser/generator with both SAX/DOM-style API.
>
> http://code.google.com/p/rapidjson/
>
> It is inspired by rapidxml, for its lightweight (rapidjson's SAX API only
> needs few hundred lines of code), and high performance.
>
> In my performance benchmark
>
> http://code.google.com/p/rapidjson/wiki/Performance
>
> the particular test case shows that rapidjson is faster than YAJL and
> JsonCpp, and the parsing speed is in the order of magnitude of strlen().
>
> I am actually new to JSON, and I did not heavily use of it in my projects.
> I really want to gather opinions. I have some immediate questions:
>
> 1. Is there any JSON dataset suitable for performance comparison?
> 2. Which JSON parsrs/generators are fast?
> 3. I tried to make rapidjson RFC4327 full-compliance. I have tested it
> with jsonchecker's test suite. Is there any other test suites for proving a
> parser's correctness?
> 4. Apart from RFC4627, is there any other add-on features which are
> important to support?
>
> Besides, I will try to provide more documentation (user guide, design,
> memory benchmarks, etc.) soon.
>
> Thank you for your attention.
>
> Best regards,
>
> Milo Yip.
>
>
>



--
--
Jonas Tärnström
Product Manager
• e-mail: jonas.tarnstrom@...
• skype: full name "Jonas Tärnström"
• phone: +46 (0)734 231 552

ESN Social Software AB
www.esn.me


[Non-text portions of this message have been removed]

Hi,

Your project looks interesting, especially the benchmark method can
help understand the performance in more details.

I will try to put your parser and the testing methodology in to my
test suite. I think these "competitions" can be help improving
projects in the community in the good way.

By the way, rapidjson is more focus on using C++ and some techniques
to boost the performance. I have no plan to develop bindings for it,
yet.

Cheers

2011/11/22 Jonas Tärnström <jonas.tarnstrom@...>:
> Hi
> My project UltraJSON (BSD license) could serve as the JSON encoder/decoder
> back-end for this if you're going for absolute performance. AFAIK there
> isn't anything faster out there.
>
> Have look at https://github.com/esnme/ultrajson
>
> The interface for encoder and decoder are structs of function pointers
> which can be bound to any language. The current integration is how ever
> made in CPython
>
> But then again, maybe we're in competition :)
>
> Cheers
> //JT

--
Milo Yip

http://www.cnblogs.com/miloyip/
http://weibo.com/miloyip/
http://twitter.com/miloyip/

Hello,
I was sent a message on sourceforge a while ago about someone doing a benchmark
test of the most popular c++ json libraries.  

He compared json_spirit (Boost), CAJUN, and libjson.  He attempted to include
jsoncpp in his tests, but said he couldn't get it to compile.

I was sent the results this
weekend: http://lijoblogs.blogspot.com/2011/11/comparison-and-benchmark-of-c-jso\
n.html  

I was surprised that json_spirit performed so poorly considering it's part of
Boost.  CAJUN ran more than five times faster than it and libjson ran almost
FIVE HUNDRED times faster than it.


Jon

[Non-text portions of this message have been removed]

This benchmark seems to test the wrong thing. A library that is lazy in
parsing and pre-serializes on each update would likely perform poorly in
real operation but would outperform all others according to this benchmark.
On Nov 22, 2011 4:09 PM, "jonathan wallace" <ninja9578@...> wrote:

> **
>
>
> Hello,
> I was sent a message on sourceforge a while ago about someone doing a
> benchmark test of the most popular c++ json libraries.
>
> He compared json_spirit (Boost), CAJUN, and libjson.  He attempted to
> include jsoncpp in his tests, but said he couldn't get it to compile.
>
> I was sent the results this weekend:
> http://lijoblogs.blogspot.com/2011/11/comparison-and-benchmark-of-c-json.html
>
> I was surprised that json_spirit performed so poorly considering it's part
> of Boost.  CAJUN ran more than five times faster than it and libjson ran
> almost FIVE HUNDRED times faster than it.
>
> Jon
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

Oops, I mentioned that to the benchmarker, I thought he altered the benchmark.
 You can see the benchmark to libjson fully parsing in the comment of the thread
he posted on my
sourceforge: http://sourceforge.net/projects/libjson/forums/forum/1119661/topic/\
4756047



________________________________
  From: Rob Meijer <pibara@...>
To: json@yahoogroups.com
Sent: Thursday, November 24, 2011 12:34 AM
Subject: Re: [json] c++ library benchmark

This benchmark seems to test the wrong thing. A library that is lazy in
parsing and pre-serializes on each update would likely perform poorly in
real operation but would outperform all others according to this benchmark.
On Nov 22, 2011 4:09 PM, "jonathan wallace" <ninja9578@...> wrote:

> **
>
>
> Hello,
> I was sent a message on sourceforge a while ago about someone doing a
> benchmark test of the most popular c++ json libraries.
>
> He compared json_spirit (Boost), CAJUN, and libjson.  He attempted to
> include jsoncpp in his tests, but said he couldn't get it to compile.
>
> I was sent the results this weekend:
> http://lijoblogs.blogspot.com/2011/11/comparison-and-benchmark-of-c-json.html
>
> I was surprised that json_spirit performed so poorly considering it's part
> of Boost.  CAJUN ran more than five times faster than it and libjson ran
> almost FIVE HUNDRED times faster than it.
>
> Jon
>
> [Non-text portions of this message have been removed]
>
> 
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links



[Non-text portions of this message have been removed]

Does the value type have to be a string, or does it support the other
types, e.g. true/false, numbers, objects, arrays, etc.  I believe it should
be any valid json.  Otherwise it's of limited usefulness.  Some examples:

original document:
{
   "foo": "bar"
}

patch:
[
    { "add": "/foo/obj", "value": {} },
    { "add": "/foo/obj/bool", "value": true },
    { "add": "/foo/obj/int", "value": 123 },
    { "add": "/foo/obj/dec", "value": 123.12 },
    { "add": "/foo/arr", "value": [] },
    { "add": "/foo/arr/0", "value": "x" }
]

resulting document:
{
   "foo": "bar",
   "obj": {
          "bool" : true,
          "int": 123,
          "dec": 123.12
   },
   "arr": [ "x" ]
}


[Non-text portions of this message have been removed]

Sorry, messed up the patch portion a little bit.  It should be this instead:
  patch:
  [
     { "add": "/obj", "value": {} },
     { "add": "/obj/bool", "value": true },
     { "add": "/obj/int", "value": 123 },
     { "add": "/obj/dec", "value": 123.12 },
     { "add": "/arr", "value": [] },
     { "add": "/arr/0", "value": "x" }
  ]


--- In json@yahoogroups.com, Ted Elliott <elliott.ted@...> wrote:
>
> Does the value type have to be a string, or does it support the other
> types, e.g. true/false, numbers, objects, arrays, etc.  I believe it should
> be any valid json.  Otherwise it's of limited usefulness.  Some examples:
>
> original document:
> {
>   "foo": "bar"
> }
>
> patch:
> [
>    { "add": "/foo/obj", "value": {} },
>    { "add": "/foo/obj/bool", "value": true },
>    { "add": "/foo/obj/int", "value": 123 },
>    { "add": "/foo/obj/dec", "value": 123.12 },
>    { "add": "/foo/arr", "value": [] },
>    { "add": "/foo/arr/0", "value": "x" }
> ]
>
> resulting document:
> {
>   "foo": "bar",
>   "obj": {
>          "bool" : true,
>          "int": 123,
>          "dec": 123.12
>   },
>   "arr": [ "x" ]
> }
>
>
> [Non-text portions of this message have been removed]
>

It supports any value type, including objects and arrays.

Paul

On Thu, 2011-12-01 at 09:05 -0500, Ted Elliott wrote:

>
>
> Does the value type have to be a string, or does it support the other
> types, e.g. true/false, numbers, objects, arrays, etc. I believe it
> should
> be any valid json. Otherwise it's of limited usefulness. Some
> examples:
>
> original document:
> {
> "foo": "bar"
> }
>
> patch:
> [
> { "add": "/foo/obj", "value": {} },
> { "add": "/foo/obj/bool", "value": true },
> { "add": "/foo/obj/int", "value": 123 },
> { "add": "/foo/obj/dec", "value": 123.12 },
> { "add": "/foo/arr", "value": [] },
> { "add": "/foo/arr/0", "value": "x" }
> ]
>
> resulting document:
> {
> "foo": "bar",
> "obj": {
> "bool" : true,
> "int": 123,
> "dec": 123.12
> },
> "arr": [ "x" ]
> }
>
> [Non-text portions of this message have been removed]
>
>
>
>
>



[Non-text portions of this message have been removed]

I've submitted the latest JSON Patch Internet-Draft, posted here:

http://tools.ietf.org/html/draft-pbryan-json-patch-03

It includes new "move" and "test" operations, and addresses some
phrasing issues that were raised. Your review and feedback will be
appreciated.

Paul


[Non-text portions of this message have been removed]

I quickly submitted another JSON Patch Internet-Draft, now posted here:

http://tools.ietf.org/html/draft-pbryan-json-patch-04

It now provides a usage example for each operation, fixes a few overt
typographical errors and cleans up further ambiguous phrasing.

Your review and feedback would be appreciated.

Paul


[Non-text portions of this message have been removed]

Interesting proposal, it could be useful, but it still need some work ;-)

I'm not sure if it's best using pure path / url syntax to find the target
element or the JavaScript dot notation. As JSON means JavaScript Object
Notation, maybe JSON Patch could use the JSON Path proposal
(https://developer.mozilla.org/en/JSON/JSONPath) for which we can already find
some implementations:
- http://code.google.com/p/jsonpath/downloads/list
- http://search.cpan.org/~tobyink/JSON-Path-0.101/lib/JSON/Path.pm
-
http://rest-assured.googlecode.com/svn/tags/1.4.5/apidocs/com/jayway/restassured\
/path/json/JsonPath.html
- http://www.sitepen.com/blog/2008/03/17/jsonpath-support/

I think it would be really more readable when you target Array indexes

in your example
{
     { "add": "/foo/1", "value": "qux" }
}
is more readable like this for many languages
{
     { "add": "foo[1]", "value": "qux" }
}
(even those using round brackets)

Maybe JSON Path does a bit too much, but at least array slices are better
handled

About the operations, I think more informations may be required.

Are JSON Patch services meant to support cross-typed operations? Which behavior
should we expect?
-> sure that saying no-support is easier

When a path is not applicable to a JSON document, should the implementation try
to build the missing part of the structure?
-> saying "no" would surely be easier, but some may be frustrated ;-)

What if there is a scalar value at some point of the path in the targeted JSON
document? Should it be overridden?
-> an error in the current state, but if the previous point is supported... it
might support a media type parameter (ex: "application/json-patch;
override=true")





--- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
>
> I quickly submitted another JSON Patch Internet-Draft, now posted here:
>
> http://tools.ietf.org/html/draft-pbryan-json-patch-04
>
> It now provides a usage example for each operation, fixes a few overt
> typographical errors and cleans up further ambiguous phrasing.
>
> Your review and feedback would be appreciated.
>
> Paul
>
>
> [Non-text portions of this message have been removed]
>

Thanks for the feedback. My comments inline:

On Mon, 2011-12-05 at 09:15 +0000, alexandre_morgaut wrote:

>
>
> Interesting proposal, it could be useful, but it still need some
> work ;-)
>
> I'm not sure if it's best using pure path / url syntax to find the
> target element or the JavaScript dot notation. As JSON means
> JavaScript Object Notation, maybe JSON Patch could use the JSON Path
> proposal (https://developer.mozilla.org/en/JSON/JSONPath) for which we
> can already find some implementations:
> - http://code.google.com/p/jsonpath/downloads/list
> - http://search.cpan.org/~tobyink/JSON-Path-0.101/lib/JSON/Path.pm
> -
>
http://rest-assured.googlecode.com/svn/tags/1.4.5/apidocs/com/jayway/restassured\
/path/json/JsonPath.html
> - http://www.sitepen.com/blog/2008/03/17/jsonpath-support/

The first draft of JSON Patch actually used JSON Path. Since JSON Path
was not standardized, I had to choose to try to standardize JSON Path or
do something else. For other reasons, we also needed a syntax that would
be very easy to express in a URI fragment identifier. JSON Schema
developed a simple syntax, which was very straightforward to implement—
much simpler even if you only kept dot and bracket notation and dumped
the rest. This was spun-off into the JSON Pointer specification.


> I think it would be really more readable when you target Array indexes
>
> in your example
> {
> { "add": "/foo/1", "value": "qux" }
> }
> is more readable like this for many languages
> {
> { "add": "foo[1]", "value": "qux" }
> }
> (even those using round brackets)
>
> Maybe JSON Path does a bit too much, but at least array slices are
> better handled
>
> About the operations, I think more informations may be required.
>
> Are JSON Patch services meant to support cross-typed operations? Which
> behavior should we expect?
> -> sure that saying no-support is easier

Not sure what you mean by cross-typed operations. Can you replace a
number with a string or object? Yes.


> When a path is not applicable to a JSON document, should the
> implementation try to build the missing part of the structure?
> -> saying "no" would surely be easier, but some may be frustrated ;-)

The latest text in draft 04 attempts to address this question and
results in the answer being no: "The location must reference one of: the
root of the target document, a member to add to an existing object, or
an element to add to an existing array."


> What if there is a scalar value at some point of the path in the
> targeted JSON document? Should it be overridden?
> -> an error in the current state, but if the previous point is
> supported... it might support a media type parameter (ex:
> "application/json-patch; override=true")

No, by the text I quoted above, it cannot be overridden.

Paul



[Non-text portions of this message have been removed]

> The first draft of JSON Patch actually used JSON Path. Since JSON Path
> was not standardized, I had to choose to try to standardize JSON Path or
> do something else. For other reasons, we also needed a syntax that would
> be very easy to express in a URI fragment identifier. JSON Schema
> developed a simple syntax, which was very straightforward to implementâ€"
> much simpler even if you only kept dot and bracket notation and dumped
> the rest. This was spun-off into the JSON Pointer specification.

I think JSONPath is kind of a de facto standard. It was chosen by ebay to create
its new SQL variant ( http://ql.io/examples )

I like JSON Schema but I'm not fan of this JSON Pointer draft. The JSON Path or
Pointer reference something inside the representation (HTTP Body). So yes, it
could be inserted with benefits in the fragment part of the URL as it is
proposed for plain text (RFC 5147) or W3C Media fragments.

Fragments are always URL encoded either if they look as a URL like path or a
JavaScript like path... I agree it'd be great to have the author propose a draft
to the IETF


> Not sure what you mean by cross-typed operations. Can you replace a
> number with a string or object? Yes.

I meant something like a "add" of a number to a string

Regards,
Alexandre

On Mon, 2011-12-05 at 17:56 +0000, alexandre_morgaut wrote:


> > The first draft of JSON Patch actually used JSON Path. Since JSON
> Path
> > was not standardized, I had to choose to try to standardize JSON
> Path or
> > do something else. For other reasons, we also needed a syntax that
> would
> > be very easy to express in a URI fragment identifier. JSON Schema
> > developed a simple syntax, which was very straightforward to
> implementâ€"
> > much simpler even if you only kept dot and bracket notation and
> dumped
> > the rest. This was spun-off into the JSON Pointer specification.
>
> I think JSONPath is kind of a de facto standard. It was chosen by ebay
> to create its new SQL variant ( http://ql.io/examples )
>
> I like JSON Schema but I'm not fan of this JSON Pointer draft. The
> JSON Path or Pointer reference something inside the representation
> (HTTP Body). So yes, it could be inserted with benefits in the
> fragment part of the URL as it is proposed for plain text (RFC 5147)
> or W3C Media fragments.
>
> Fragments are always URL encoded either if they look as a URL like
> path or a JavaScript like path... I agree it'd be great to have the
> author propose a draft to the IETF
>
> > Not sure what you mean by cross-typed operations. Can you replace a
> > number with a string or object? Yes.
>
> I meant something like a "add" of a number to a string


No, this specification does not support mathematical, logical or string
operations.

Paul



[Non-text portions of this message have been removed]

{"hello":"bson"}
\x15 \x00 \x00 \x00 \x02 h e l l o \x00 \x05 \x00 \x00 \x00 b s o n \x00 \x00

I already read from this link : http://bsonspec.org/#/specification
but stil confused.
Can anyone explain what \x15 & why start \x15?
what \x02 before "hello"?
what \x05?
thanks in advance

Wrong mailing list -- you probably want to join
http://groups.google.com/group/bson since this is related to BSON, not
json.

-+ Tatu +-

On Sun, Dec 11, 2011 at 8:13 PM, zaqi <slash_jak@...> wrote:
>                        {"hello":"bson"}
> \x15 \x00 \x00 \x00 \x02 h e l l o \x00 \x05 \x00 \x00 \x00 b s o n \x00 \x00
>
> I already read from this link : http://bsonspec.org/#/specification
> but stil confused.
> Can anyone explain what \x15 & why start \x15?
> what \x02 before "hello"?
> what \x05?
> thanks in advance
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

I'm hoping someone can help explain the rationale behind a couple of
points in the JSON specification:

1. 8bit content-transfer-encoding for UTF-8

RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
was 8bit selected rather than binary content-transfer-encoding? This
limits the length of JSON strings to 994 octets.

2. Non-unique object members

RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
selected rather than MUST?

Paul

On Sun, Jan 1, 2012 at 9:50 PM, Paul C. Bryan <paul.bryan@...> wrote:
> I'm hoping someone can help explain the rationale behind a couple of
> points in the JSON specification:
>
> 1. 8bit content-transfer-encoding for UTF-8
>
> RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
> was 8bit selected rather than binary content-transfer-encoding? This
> limits the length of JSON strings to 994 octets.

Hmmh? Where does 994 come from?

> 2. Non-unique object members
>
> RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
> selected rather than MUST?

I assume this was to allow implementations to choose whether they keep
track of all seen names or not: this can add non-trivial overhead for
storage requirements, especially when processing JSON data streams.

-+ Tatu +-

Paul C. Bryan scripsit:

> RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible."

I think that statement is just a false assertion rather than a normative
restriction.

> This limits the length of JSON strings to 994 octets.

Nobody imposes any such limit.

> 2. Non-unique object members
>
> RFC 4627: "The names within an object SHOULD be unique." Why was
> SHOULD selected rather than MUST?

That's a very good question.

--
We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.
Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
fishes, for a poor creature, and they say death.  So wise they are; so just,
so very just.  --Gollum        cowan@...  http://ccil.org/~cowan

Tatu Saloranta scripsit:

> > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
> > was 8bit selected rather than binary content-transfer-encoding? This
> > limits the length of JSON strings to 994 octets.
>
> Hmmh? Where does 994 come from?

From RFC 2045:

2.8.  8bit Data

    "8bit data" refers to data that is all represented as relatively
    short lines with 998 octets or less between CRLF line separation
    sequences [RFC-821]), but octets with decimal values greater than 127
    may be used.  As with "7bit data" CR and LF octets only occur as part
    of CRLF line separation sequences and no NULs are allowed.

> > 2. Non-unique object members
> >
> > RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
> > selected rather than MUST?
>
> I assume this was to allow implementations to choose whether they keep
> track of all seen names or not: this can add non-trivial overhead for
> storage requirements, especially when processing JSON data streams.

Good point.

--
With techies, I've generally found              John Cowan
If your arguments lose the first round          http://www.ccil.org/~cowan
     Make it rhyme, make it scan                 cowan@...
     Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie

On Sun, 2012-01-01 at 23:11 -0800, Tatu Saloranta wrote:

> Hmmh? Where does 994 come from?

Sorry, 996 octets. I think.

Per RFC 2045 §2.8, 8bit data is "...represented as relatively short
lines with 998 octets or less between CRLF line separation sequences..."

Given that a JSON string must be encapsulated in quotation marks (2
octets), this seems to limit the number of octets that can be expressed
in a UTF-8 encoded JSON string to 996 octets.

Paul

On Sun, Jan 1, 2012 at 11:32 PM, Paul C. Bryan <paul.bryan@...> wrote:
> On Sun, 2012-01-01 at 23:11 -0800, Tatu Saloranta wrote:
>
>> Hmmh? Where does 994 come from?
>
> Sorry, 996 octets. I think.
>
> Per RFC 2045 §2.8, 8bit data is "...represented as relatively short
> lines with 998 octets or less between CRLF line separation sequences..."
>
> Given that a JSON string must be encapsulated in quotation marks (2
> octets), this seems to limit the number of octets that can be expressed
> in a UTF-8 encoded JSON string to 996 octets.

I am quite sure this was not the intent -- such limit would indeed
render JSON pretty useless.

-+ Tatu +-