To save people looking it up:

ECMA-262, section 7.6:

Two IdentifierName that are canonically equivalent according to the
Unicode standard are not equal unless they are represented by the
exact same sequence of code units (in other words, conforming
ECMAScript implementations are only required to do bitwise comparison
on IdentifierName values). The intent is that the incoming source text
has been converted to normalised form C before it reaches the
compiler.

ECMAScript implementations may recognize identifier characters defined
in later editions of the Unicode Standard. If portability is a
concern, programmers should only employ identifier characters defined
in Unicode 3.0.

There then follows a syntax definition, which expressly precludes use
of reserved keywords from being identifiers.

Looks like the most interesting attacks on json, from a security
viewpoint, would be using keywords as object member names.
Has anyone checked what happens if you do? I suspect the javascript
implementations would be the most at risk.

I think it's fairly clear that a JSON parser has ABSOLUTELY NO
BUSINESS poking around with actual data strings; Douglas has been very
clear that you are to pass them bit-identical to the recipient. On the
other hand, there's an argument for some kind of sanitation when it
comes to object member names.
I'm really tempted by the idea of a JSON-secure spec, which clamps
down on these details.

Arguing the Unicode details is decidedly NOT compatible with the
"spirit" of JSON, which Douglas has been very clear about; a
lightweight, simple, modern data representation.

I think it speaks to the merit of JSON as a format that you (@Johne)
want to consider the security details.
But I think what you need might well be a branch and a new spec?

I'm probably speaking way out of turn here, so please do accept my
apologies if I've overstepped any bounds.

Best,

Dave.




On Wed, Mar 2, 2011 at 6:22 PM, Dave Gamble <davegamble@...> wrote:
>
> Better question: How does the ECMA/javascript spec limit variable names?
> This seems to be the same question, in practical terms.
> Dave.
>
> On Wed, Mar 2, 2011 at 6:21 PM, Dave Gamble <davegamble@...> wrote:
>>
>> Would it be too much to specify that key names are to be ASCII top-bit-unset
strings?
>> i.e. in the definition of an object, designate that the "string" there is a
"simplestring" which uses a restricted definition of char?
>> As far as I can see, this is the only case where the Unicode interpretation
is potentially dangerous.
>> In usage of strings as data, I believe they are to be delivered unprocessed
to the user of the data.
>> Maybe designate this json_littlebitmoresecure.
>> Cheers,
>> Dave.
>>
>> On Wed, Mar 2, 2011 at 4:46 AM, johne_ganz <john.engelhart@...> wrote:
>>>
>>>
>>>
>>> --- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
>>> >
>>> > johne_ganz scripsit:
>>> >
>>> > > In fact, for my parser (JSONKit), which is Objective-C based and uses
>>> > > NSString to represent the JSON String objects, it is not practical
>>> > > for me to create a JSON parser that "respects the data stored in the
>>> > > JSON byte stream". The NSString class makes no such guarantees in its
>>> > > documentation, nor does the Unicode Standard. It would be extremely
>>> > > non-trivial for me to meet a "respects the data stored in the JSON
>>> > > byte stream" requirement, at least in the sense that the behavior
>>> > > is deterministic.
>>> >
>>> > Normalization is non-trivial, and I doubt if any existing Unicode library
>>> > imposes it on all strings at creation/modification time. Certainly ICU
>>> > does not; it provides the ability to normalize, that's all.
>>>
>>> The Foundation framework (specifically the NSString class) on Mac OS X and
iPhone / iPad does. Not sure if 90+ million iPhones count for much, though.
>>>
>>> In particular, [@"Ä" compare:@"Ä"] is zero, or "identical", whereas [@"Ä"
isEqual:@"Ä"] is "no". Each has different semantics, and -compare: is preferred
when dealing with strings because it has the right semantics in that context.
>>>
>>> As an analogy, it would be as if Javascript behaved as:
>>> if("Ä" == "Ä") // True
>>> if("Ä" === "Ä") // False
>>> in the same way that ("1" == 1) is true, but ("1" === 1) is false.
>>>
>>> And just in case things get mangled along the way, the first string is
"\u00c4" and the second string is "\u0041\u0308". In fact, if they do get
mangled.... I think that should serve as a warning that these things can and do
happen behind your back when dealing with Unicode.
>>>
>>>
>

On Wed, Mar 2, 2011 at 6:38 PM, John Cowan <cowan@...> wrote:
>
>
>
> Dave Gamble scripsit:
>
> > Better question: How does the ECMA/javascript spec limit variable names?
> > This seems to be the same question, in practical terms.
>
> In JSON, unquoted keys are not permitted,
> so both keys and values are strings.
>
I am aware of that :)
It occurs to me that since the intention is that JSON text
deserializes into an instanced object, which will in some cases be a
javascript object (where member variable names are used), there could
be call for a greater limitation on this? Does that make sense?

In other words, my question didn't concern the JSON spec, it concerned
the limitations imposed on member variable names in javascript; since
this seemed like it might be a sensible set of limitations to apply to
JSON keys.

Dave.



>
> --
> Unless it was by accident that I had John Cowan
> offended someone, I never apologized. cowan@...
> --Quentin Crisp http://www.ccil.org/~cowan
>
>

Dave Gamble scripsit:

> Looks like the most interesting attacks on json, from a security
> viewpoint, would be using keywords as object member names.
> Has anyone checked what happens if you do? I suspect the javascript
> implementations would be the most at risk.

Indeed they would, which is precisely why {foo: "bar"} is not conformant
JSON any more than {if: "bar"} would be, although the first is conformant
JavaScript and the second is not.  However, {"foo": "bar"} and {"if":
"bar"} are both good JSON and good JavaScript, and in JavaScript {foo:
"bar"} and {"foo": "bar"} mean the same thing.

--
John Cowan  cowan@...   http://ccil.org/~cowan
Promises become binding when there is a meeting of the minds and consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today.
        --Specht v. Netscape

Dave Gamble scripsit:

> In other words, my question didn't concern the JSON spec, it concerned
> the limitations imposed on member variable names in javascript; since
> this seemed like it might be a sensible set of limitations to apply to
> JSON keys.

I don't think so.  In particular, it is often helpful to allow keys named
"$" or "#foo" or such.  In any case, the normalization rule for JavaScript
identifiers is "Don't".

--
There is no real going back.  Though I          John Cowan
may come to the Shire, it will not seem         cowan@...
the same; for I shall not be the same.          http://www.ccil.org/~cowan
I am wounded with knife, sting, and tooth,
and a long burden.  Where shall I find rest?           --Frodo

johne_ganz scripsit:

> "What does it mean for two keys (or names in RFC 4627 nomenclature)
> to compare equal?"

Actually, it doesn't mean anything, because the RFC only says that the
keys of an object SHOULD (not MUST) be unique.  In practice, people
probably parse objects into some kind of string-based hash table,
so all duplicates but the last (or possibly the first) are ignored,
and nothing is done about normalization.

--
John Cowan    http://www.ccil.org/~cowan   <cowan@...>
     "Any legal document draws most of its meaning from context.  A telegram
     that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
     5-bit Baudot code plus appropriate headers) is as good a legal document
     as any, even sans digital signature." --me

johne_ganz scripsit:

> And just in case things get mangled along the way, the first string is
> "\u00c4" and the second string is "\u0041\u0308".  In fact, if they
> do get mangled.... I think that should serve as a warning that these
> things can and do happen behind your back when dealing with Unicode.

Yup, it got here in Normalization Form C, using U+00C4 in both cases.
But that's email for you, and perhaps that's Apple for you too.  I'd stick
with isEqual.

--
[W]hen I wrote it I was more than a little              John Cowan
febrile with foodpoisoning from an antique carrot       cowan@...
that I foolishly ate out of an illjudged faith          http://ccil.org/~cowan
in the benignancy of vegetables.  --And Rosta

Is there any way to represent XSD as JSON (with the constraints intact).

--- In json@yahoogroups.com, Dave Gamble <davegamble@...> wrote:
>
> Would it be too much to specify that key names are to be ASCII top-bit-unset
> strings?
>
> i.e. in the definition of an object, designate that the "string" there is a
> "simplestring" which uses a restricted definition of char?
>
> As far as I can see, this is the only case where the Unicode interpretation
> is potentially dangerous.
> In usage of strings as data, I believe they are to be delivered unprocessed
> to the user of the data.

Restricting keys to < U+0080 (i.e., ASCII) is one way.  Personally, I'm kinda
partial to something along the lines of this:

A JSON generator SHOULD only emit key names that are (some word smithed language
along the lines of possibly NFC, precomposed, possibly even NFKC, etc...)

A JSON generator SHOULD NOT emit keys that are (Unicode Equivalent)
(http://en.wikipedia.org/wiki/Unicode_equivalence)  (... or some word smithed
language to this effect.)

A user/application MUST NOT depend on behavior that requires two (Unicode
Equivalent) keys that are not (word smithed language for concept of 'bit
identical').

The behavior is UNDEFINED for two keys that are (Unicode Equivalent) but not
(word smithed language for concept of 'bit identical').

Two keys compared to each other are equal if they are (some word smithed
language that incorporates the concept of Unicode Equivalence).  A JSON
implementation MAY perform normalization on parsed keys, but is not required to.
A JSON parser implementation MAY treat two keys that are (Unicode Equivalent)
but not (word smithed language for concept of 'bit identical') as different, but
a parser SHOULD strive for (just Unicode Equivalent).

When "round-tripping", a user/application MUST NOT depend on behavior where two
(Unicode Equivalent) keys that are not (word smithed language for concept of
'bit identical') to remain unchanged.  (the intent is that a parser may perform
some form of normalization on the keys, so when they are round tripped, an
unnormalized key may become normalized in the process).

In other words..... this is probably fairly close to exactly how things really
are right now, it just spells it out.  It also places the responsibility for the
"problem" squarely on the user/application that's generating the keys- it should
only generate, use, and manipulate keys that respect the fact that some unicode
strings may be slightly modified from their original form, but still considered
equal.

And most of these issues can be avoided if you stick to just plain ASCII code
points, or use code points that can not be mutilated by Unicode (i.e., don't use
Å, or U+212B, which can be transformed in to either U+00C5 or U+0041 U+030A).

--- In json@yahoogroups.com, Dave Gamble <davegamble@...> wrote:
>
> To save people looking it up:
>
> ECMA-262, section 7.6:
>
> Two IdentifierName that are canonically equivalent according to the
> Unicode standard are not equal unless they are represented by the
> exact same sequence of code units (in other words, conforming
> ECMAScript implementations are only required to do bitwise comparison
> on IdentifierName values). The intent is that the incoming source text
> has been converted to normalised form C before it reaches the
> compiler.
>
> ECMAScript implementations may recognize identifier characters defined
> in later editions of the Unicode Standard. If portability is a
> concern, programmers should only employ identifier characters defined
> in Unicode 3.0.

There is another relevant section (ECMA-262, 8.4 The String Type, pg 28)

When a String contains actual textual data, each element is considered to be a
single UTF-16 code unit. Whether or not this is the actual storage format of a
String, the characters within a String are numbered by their initial code unit
element position as though they were represented using UTF-16. All operations on
Strings (except as otherwise stated) treat them as sequences of undifferentiated
16-bit unsigned integers; they do not ensure the resulting String is in
normalised form, nor do they ensure language-sensitive results.

NOTE The rationale behind this design was to keep the implementation of Strings
as simple and high-performing as possible. The intent is that textual data
coming into the execution environment from outside (e.g., user input, text read
from a file or received over the network, etc.) be converted to Unicode
Normalised Form C before the running program sees it. Usually this would occur
at the same time incoming text is converted from its original character encoding
to Unicode (and would impose no additional overhead). Since it is recommended
that ECMAScript source code be in Normalised Form C, string literals are
guaranteed to be normalised (if source text is guaranteed to be normalised), as
long as they do not contain any Unicode escape sequences.

> I think it's fairly clear that a JSON parser has ABSOLUTELY NO
> BUSINESS poking around with actual data strings; Douglas has been very
> clear that you are to pass them bit-identical to the recipient. On the
> other hand, there's an argument for some kind of sanitation when it
> comes to object member names.
> I'm really tempted by the idea of a JSON-secure spec, which clamps
> down on these details.

I disagree with your first statement.  The ECMA-262 standard, at least in my
opinion, tries to side step a lot of these issues.  It makes a fairly clear
distinction between "what happens inside the ECMA-262 environment (which it
obviously has near total control over)" and "what happens outside the ECMA-262
environment".

IMHO, the ECMA-262 standard advocates that "stuff that happens outside the
ECMA-262 environment should be treated as if it is NFC".

Since the sine qua non of JSON is the interchange of information between
different environments and implementations, it must address any issues that can
and will cause difficulties.  Like it or not, the fact that it's Unicode means
these things can and will happen, and it's simply not practical to expect or
insist that every implementation treat JSON Strings as "just a simple array of
Unicode Code Points".

> Arguing the Unicode details is decidedly NOT compatible with the
> "spirit" of JSON, which Douglas has been very clear about; a
> lightweight, simple, modern data representation.

I completely agree that these details are NOT compatible with the "spirit" of
JSON.

But.... so what?  Unicode is not simple.  I'm not the one who made it that way,
but the way that RFC 4627 is written, you must deal with it.  There are ways RFC
4627 could have been written such that the JSON to be parsed is considered a
stream of 8 bit bytes, and therefore stripped of its Unicode semantics (if any).
However, it very clearly and plainly says "JSON text SHALL be encoded in
Unicode.", which pretty much kills the idea that you can just treat it as raw
bytes.

There's a saying about formalized standards:  The standard is right.  Even it's
mistakes.

As an aside, there is a RFC for "Unicode Format for Network Interchange", RFC
5198 (http://tools.ietf.org/html/rfc5198).  It is 18 pages long.  RFC 4627 is
just 9 pages.

Actually, I would encourage people to read RFC 5198.  I'm not sure I agree with
all of it, but it goes over a lot of the issues I think are very relevant to
this conversation.  It's great background info if you're not familiar with the
details.

Just as the subject suggests... Do you need to double quote numeric values to be
valid JSON? JSONlint seems to validate the following string just fine: 
{"age":35}

I believe the part in the spec that says all STRINGS must be double quoted
doesn't apply to numeric values as they are not strings...yes?


Thanks

toddkingham scripsit:
> Just as the subject suggests... Do you need to double quote numeric
> values to be valid JSON? JSONlint seems to validate the following
> string just fine:  {"age":35}

So it should: strings are quoted, numbers are not.

> I believe the part in the spec that says all STRINGS must be double
> quoted doesn't apply to numeric values as they are not strings...yes?

Right.

--
John Cowan  cowan@...  http://ccil.org/~cowan
In computer science, we stand on each other's feet.
         --Brian K. Reid

Thanks.... that was fast :)

--- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
>
> toddkingham scripsit:
> > Just as the subject suggests... Do you need to double quote numeric
> > values to be valid JSON? JSONlint seems to validate the following
> > string just fine:  {"age":35}
>
> So it should: strings are quoted, numbers are not.
>
> > I believe the part in the spec that says all STRINGS must be double
> > quoted doesn't apply to numeric values as they are not strings...yes?
>
> Right.
>
> --
> John Cowan  cowan@...  http://ccil.org/~cowan
> In computer science, we stand on each other's feet.
>         --Brian K. Reid
>

{"age":35}

{"age":"35"}

Are both legal JSON, but very different objects.  In the first, age is the
number 35, the second is a string with characters '3' and '5'.
 
"People have always been impressed by the power of our example, not the example
of our power." - William Jefferson Clinton


________________________________
From: toddkingham <toddkingham@...>
To: json@yahoogroups.com
Sent: Friday, March 11, 2011 5:16 PM
Subject: [json] Do numeric values need to be double quoted when returned in
objects?


 
Just as the subject suggests... Do you need to double quote numeric values to be
valid JSON? JSONlint seems to validate the following string just fine: 
{"age":35}

I believe the part in the spec that says all STRINGS must be double quoted
doesn't apply to numeric values as they are not strings...yes?

Thanks







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

Hi All,

I'm sure this has been asked before but I cannot find it here, so here is my
question

Is there a simple way to convert/deserialize and JSON object into a Java bean? 
There is the toBean() method but that looks like it is only for primitives.  I
know you can convert a Java bean to a JSON object.

GSON has something I could use but I don't want to use GSON.

Any help or thoughts would be great.

Travis...

On Mon, Mar 28, 2011 at 2:15 PM, gtcul
<travis.culbreth@...> wrote:
> Hi All,
>
> I'm sure this has been asked before but I cannot find it here, so here is my
question
>
> Is there a simple way to convert/deserialize and JSON object into a Java bean?
 There is the toBean() method but that looks like it is only for primitives.  I
know you can convert a Java bean to a JSON object.
>
> GSON has something I could use but I don't want to use GSON.

You are better of using a package that does data binding, such as
Jackson or GSON.

-+ Tatu +-

Jansson 2.0.1 is out. This release fixes a few bugs, some of them
major and some minor.

The most important bug fixes are:

* Fix strict key checking in json_unpack() code
* Fix the return value of json_object_size()
* Fix a few segfaulters when custom memory management is used
* Make the JANSSON_VERSION_HEX constant usable

For full details, see the changelog.

Download source: http://www.digip.org/jansson/releases/jansson-2.0.1.tar.gz
View documentation: http://www.digip.org/jansson/doc/2.0/
Changelog: http://www.digip.org/jansson/doc/2.0/changes.html#version-2-0-1


What is Jansson?
----------------

Jansson is a C library for encoding, decoding and manipulating JSON data.
It features:

* Simple and intuitive API and data model
* Comprehensive documentation
* No dependencies on other libraries
* Full Unicode support (UTF-8)
* Extensive test suite

Jansson is licensed under the MIT license.

For more details, see http://www.digip.org/jansson/.


Petri Lehtinen

This is mainly for Mr D and it's about json2.js ( probably the sans eval as
well )

If I create an object through a VBScript class definition and this object
has a hosted toJSON public method the parser will fail, while it does not
fail with native IE8 and IE9 implementation.

The change should be straight forward, where there is a check about the
method type there should be an "unknown" as well.

In few words:

if (typeof object === "object" && (typeof object.toJSON === "function" ||
typeof object.toJSON === "unknown")) {
     value = object.toJSON(key);
}

Above code will already work as expected but to be honest I would rather
make the check more portable

function invokeToJSON(object, method, key) {
     switch (typeof object[method]) {
         case "function":
         case "unknown":
             try {
                 return typeof key === "string" ?
                     object[method]() :
                     object[method](key)
                 ;
             } catch(e) {
                 // notify something here
             }
     }
}

// so that ...

if (typeof object === "object") {
     value = invokeToJSON(object, "toJSON", key);
}

// then if value is not undefined ...

the function could be reused for toString and valueOf, if necessary, without
a key argument since VBScript methods are sensible to arguments length.

Any comment/improvement will be appreciated, any update on github more than
welcome.

Best Regards,
     Andrea Giammarchi

P.S. "unknown" is IE specific


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

--- In json@yahoogroups.com, Andrea Giammarchi <andrea.giammarchi@...> wrote:
>
> This is mainly for Mr D and it's about json2.js ( probably the sans eval as
> well )
>
> If I create an object through a VBScript class definition and this object
> has a hosted toJSON public method the parser will fail, while it does not
> fail with native IE8 and IE9 implementation.
>
> The change should be straight forward, where there is a check about the
> method type there should be an "unknown" as well.
>
> In few words:
>
> if (typeof object === "object" && (typeof object.toJSON === "function" ||
> typeof object.toJSON === "unknown")) {
>     value = object.toJSON(key);
> }
>
> Above code will already work as expected but to be honest I would rather
> make the check more portable
>
> function invokeToJSON(object, method, key) {
>     switch (typeof object[method]) {
>         case "function":
>         case "unknown":
>             try {
>                 return typeof key === "string" ?
>                     object[method]() :
>                     object[method](key)
>                 ;
>             } catch(e) {
>                 // notify something here
>             }
>     }
> }
>
> // so that ...
>
> if (typeof object === "object") {
>     value = invokeToJSON(object, "toJSON", key);
> }
>
> // then if value is not undefined ...
>
> the function could be reused for toString and valueOf, if necessary, without
> a key argument since VBScript methods are sensible to arguments length.
>
> Any comment/improvement will be appreciated, any update on github more than
> welcome.
>
> Best Regards,
>     Andrea Giammarchi
>
> P.S. "unknown" is IE specific

I am happy that you were able to get it working, but I have to tell you, I have
absolutely no interest in supporting VBScript or typeof unknown. I have a very
strong interest in seeing that crap go extinct.

Me too, unfortunately that crap may be useful to create HTML5 shims due
getters/setters possibility: e.g. Objet.create, localStorage with direct
property assignment, etc. Since this is a IE 7 or less case only, since IE8
supports VBScript with a toJSON method, I don't think it can arm anybody
else, also because json2.js is the file that hopefully gonna be extinct
soon, isn't it?

Moreover, if IE8 native JSON.stringify supports that, isnt's this json2.js
goal to bring this object in those browsers that do not support it?

Best Regards,
     Andrea Giammarchi


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

Since I've received a number of requests for more security options in libjson,
I'm in the process of adding them and I have two questions regarding the default
values.  libjson will allow you to change these values, but I want to set a
default.

My new security features protect against DoS attacks.  I have a maximum nesting
depth option and a maximum json length option.  My current defaults are 100
nests maximum and 32MB length maximum.  I would like to know everyone's opinion
on these values.  I know PHP has a max nest limit of 128 and no length limit.

Jon

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

I have set nest depth to 10 but I'm checking object structures in fastJSON for
.net which seems more than enough. Size limit is tricky as you might have to
transfer large rows of data in datasets which could easily go over 32mb, so I'm
not checking for that.

Hope that helps.


On 2011-04-06 02:10, jonathan wallace wrote:
>
> Since I've received a number of requests for more security options in
> libjson, I'm in the process of adding them and I have two questions
> regarding the default values. �libjson will allow you to change these
> values, but I want to set a default.
>
> My new security features protect against DoS attacks. �I have a
> maximum nesting depth option and a maximum json length option. �My
> current defaults are 100 nests maximum and 32MB length maximum. �I
> would like to know everyone's opinion on these values. �I know PHP has
> a max nest limit of 128 and no length limit.
>
> Jon
>
> [Non-text portions of this message have been removed]
>
>



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

The JSON page is now available in Serbian, thanks to Dragan Sretenović.

http://json.org/json-sr.html

Hi, all!

i thought one or two of you might find a use for this:

http://fossil.wanderinghorse.net/repos/cson/index.cgi/wiki/select-to-json

It's a small C app which connects to a sqlite3 or mysql database, runs
arbitrary SELECT queries, and sends the results as JSON to stdout.

It's untested on anything but Linux, but "should" compile as-is on most
Unix-like environments. The makefile doesn't specifically support Mac (nor
do i) nor Cygwin, but someone out there can certainly figure out how to do
it. The code is portable C89, and "could" work on Windows once a proper
project file is set up for it.

Happy Hacking!

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


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

I've published an informational Internet-Draft for JSON Patch, a
proposed structure for specifying partial modifications to JSON
documents. You can see it at:

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

One of the primary motivations is to have a media type that can be used
with HTTP PATCH (RFC 5789).

Any feedback would be most appreciated.

Paul


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

On Sun, 2011-04-24 at 18:37 -0600, Kris Zyp wrote (in response to an
email I sent him before I posted in this mailing list):


> Paul,
> This looks good, I'm glad you are working on this. A few comments:
> * There are few things that seem overly verbose. To update a property
> do you really need to a remove and add? It seems like the most common
> use case would be to update a set of properties on an object. Wouldn't
> it be preferable to do this in a more compact form? Being able to
> provide a set of properties in an update object seems like it would be
> a more efficient patch.


Point taken. In an iteration prior to publishing draft 00, I actually
had a "replace" op. It didn't take an array replacements; I was still
relying on each node to be identified by a path (so multiple replace
operations). It sounds like you'd like to have an array of
property-modifications; something like a splice for objects. Am I right?


> * It would seem that it would be nice to be able to insert/splice
> elements in and out of arrays, so the entire arrays (or all indexes
> after a splice) wouldn't have to be changed.


Remove/add will do this too, but I presume the issue is the amount of
verbosity involved?


> * In JSON Schema we have abandoned using JSONPath. JSONPath really
> doesn't have that signficant of adoption, and using URL friendly slash
> delimiting and URL encoding works better within URLs and within JSON
> strings (so you don't have to embedded quoting). See
> http://tech.groups.yahoo.com/group/json/message/1473?threaded=1 for
> more discussion on the subject.
> (if you want this discussed on the JSON ML, feel free to switch over
> there).


Okay. I definitely see RESTful advantages to using fragment identifiers
for sub-resource addressing. And this isn't the first pushback to using
JSONPath I've received. Would you consider splitting fragment
identifiers out of JSON Schema into a separate, short I-D that we can
both reference?

Paul


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

Hi Paul,

First, I like the idea of updating a json document with a json document
containing change
and from my point of view you almost got it right :).

My first remark is that the element key could be removed and moved into the path
key. The first example could then be rewritten to:

{
   "patches": [
      { "op": "remove", "path": "$.a.b.c" },
      { "op": "add", "path": "$.a.b.c", "value": "foo" }
   ]
}

or just

{
   "patches": [
      { "op": "add", "path": "$.a.b.c", "value": "foo" }
   ]
}

If we can agree that "add" is also an update if the path exists.

My second remark is that you assume zero-indexed arrays as does JSONPath by
goessner, but JSON actually doesn't mention that. And for a good reason: the
less we have to a agree on, the more likely is it that the standard will be
accepted and implemented (also no dates or timestamps in JSON).

So perhaps there should be an entry in the JSON Patch document which specifies
what index base is being used.

Third remark: You say that path must resolve to a single node, then perhaps
JSONPath is overkill in comparison to what you want to do. JSONPath is very
powerful but also complex and unlikely to be implemented widely across
JSON-implementations (a must for making JSON Patch widely accepted). Perhaps you
should write a simple grammar for JSON Patch path values.

In my little JSON implementation, PL/JSON, i've written a small grammar that you
can steal or modify if you wan't. Then your open issue 1 will also be resolved.

You can read about the grammar on page 5-7 in the file doc.pdf from
http://sourceforge.net/projects/pljson/ . The main difference is that you don't
specify the root element and that double quotes also are allowed. Ohh and it
uses one-based indexing, but that could easily be modified.

Hope that you can use some of my suggestions.

/Jonas

BTW: Is it legal to add information in a JSON Patch document that specifies
where or how to find the document that should be patched?

--- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
>
> I've published an informational Internet-Draft for JSON Patch, a
> proposed structure for specifying partial modifications to JSON
> documents. You can see it at:
>
> http://tools.ietf.org/html/draft-pbryan-json-patch-00
>
> One of the primary motivations is to have a media type that can be used
> with HTTP PATCH (RFC 5789).
>
> Any feedback would be most appreciated.
>
> Paul
>
>
> [Non-text portions of this message have been removed]
>

Is there some spec for XML - JSON bi-directional conversion?

I have observed a few tools that have this feature,
including JSON-java by Douglas Crockford
<https://github.com/douglascrockford/JSON-java/blob/master>  ,
but no description of how to resolve "impedance mismatch"
between data-oriented JSON and document-oriented XML...

Here is a link to my blog comment about issues of this conversion
http://dragansr.blogspot.com/2011_04_10_archive.html#1877312882670385155
<http://dragansr.blogspot.com/2011_04_10_archive.html#187731288267038515\
5>

Thanks

Dragan



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

On Fri, Apr 29, 2011 at 5:32 AM, Dragan <dragansr@...> wrote:
>
> Is there some spec for XML - JSON bi-directional conversion?

There are multiple conventions for doing this, such as Badgerfish.

Main question is "why", that is, what is the reason for using such
conversions: mostly because it is easy to just embed XML in JSON (and
vice versa) as textual values. And while conversions are possible,
they come in two main flavors: ugly and uni-directional. So often best
way to convert is not to convert directly between XML and JSON, as
their information models are not directly compatible (there is
impedance)

-+ Tatu +-

This "impedance mismatch" has been a source of a lot of solutions with various
trade-offs. One of the first encodings is called BadgerFish which uses an '@'
prefix to distinguish attributes from child elements. Many people have created
variations of this to attempt to solve the various issues that arrise.

I created JsonML (http://jsonml.org) back in 2006 to specifically deal with
lossless bi-directional translation when the XML isn't data-centric but is
markup-centric. When there is "mixed-mode content" most other representations
can't represent it. Mixed-mode is when elements sit as siblings to textual
nodes. This is uncommon in serialized XML data, but is the norm with XML markup
like XHTML.

JsonML is a less intuitive mapping than the BadgerFish-style, but it's intent
was to be an intermediate format interpreted by machine not humans. In an email
exchange with Crockford, we settled upon using an array as the element (rather
than an object with a children array) and it reduced the size of the mapping
significantly.

The most complete list of XML-to-JSON mappings to date is on this wiki:

http://wiki.open311.org/index.php?title=JSON_and_XML_Conversion

It shows how a document could be translated between each of the formats and
gives some good detail about each.

--- In json@yahoogroups.com, "Dragan" <dragansr@...> wrote:
>
>
> Is there some spec for XML - JSON bi-directional conversion?
>
> I have observed a few tools that have this feature,
> including JSON-java by Douglas Crockford
> <https://github.com/douglascrockford/JSON-java/blob/master>  ,
> but no description of how to resolve "impedance mismatch"
> between data-oriented JSON and document-oriented XML...
>
> Here is a link to my blog comment about issues of this conversion
> http://dragansr.blogspot.com/2011_04_10_archive.html#1877312882670385155
> <http://dragansr.blogspot.com/2011_04_10_archive.html#187731288267038515\
> 5>
>
> Thanks
>
> Dragan

stephen.mckamey scripsit:

> I created JsonML (http://jsonml.org) back in 2006 to specifically
> deal with lossless bi-directional translation when the XML isn't
> data-centric but is markup-centric. When there is "mixed-mode content"
> most other representations can't represent it. Mixed-mode is when
> elements sit as siblings to textual nodes. This is uncommon in
> serialized XML data, but is the norm with XML markup like XHTML.

I'd like to push for JsonML being the official JSON-syntax
representation of the MicroXML data model, since they match perfectly:
an element has a name, attribute map, and sequence of elements.

> http://wiki.open311.org/index.php?title=JSON_and_XML_Conversion

Good to know about.

--
John Cowan    http://ccil.org/~cowan    cowan@...
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev