I've posted the second draft of the JSON Pointer Internet-Draft to the
IETF:

http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-01

It should address all of the outstanding issues that have been raised to
date. Your feedback is welcome.

Paul


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

Paul C. Bryan scripsit:

> I've posted the second draft of the JSON Pointer Internet-Draft to the
> IETF:
>
> http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-01

Examples would be good.  You also need to explain how, if at all,
non-ASCII characters are encoded.

--
Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!
   --Joyce, Ulysses, "Oxen of the Sun"       cowan@...

On Fri, Oct 21, 2011 at 7:47 AM, Paul C. Bryan <paul.bryan@...>wrote:

> **
>
> I've posted the second draft of the JSON Pointer Internet-Draft to the
> IETF:
>
> http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-01
>
> It should address all of the outstanding issues that have been raised to
> date. Your feedback is welcome.
>

i don't know if this would be useful in the larger context of your RFC, but
rather than reserving a specific path character (since library-level code
cannot expect arbitrary JSON to conform to one), in my code where i use
"path-like strings" to search for JSON data i instead require that the
caller specify the separator character (to avoid awkward encoding issues).
So, instead of a path like "foo/bar/baz", i require "XfooXbarXbaz", where X
is any character guaranteed (by the client, not the library!) to not appear
in any key name in the path. That X is then used as the separator for the
search string. This approach does not address absolute vs. relative paths,
however, and assumes that all searches are relative to an object provided by
the client.


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


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

I've quickly turned-around and submitted a third draft of the JSON
Pointer Internet-Draft to the IETF:

http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-02

It fixes a glaring error and addresses some feedback already received.

Thanks to Drew Perttula for pointing-out the glaring error. Thanks also
to Dean Landolt for his quick feedback.

Further feedback on this latest draft welcome.

Paul


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

I've posted the third draft of the JSON Patch Internet-Draft to the
IETF:

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

It should address all of the outstanding issues that have been raised to
date. Your feedback is welcome.

Paul


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

Hi,

I have juste release a new version of json-smart.
This version fixe some ugly Exception that may occur with oldest version.
User's feedback are welcome before the maven publish.

Uriel.

{
    "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
>
>
>