TrimQuery solution is right pretty, but.... not for tree-based
structures.

Visitor pattern and XPATH on XML realy designed for tree.
Before I decide on Visitor I have seen JavaScript XPATH library
written by Steffen Meschkat <mesch@...>. It's realy titanic
solution, but it's designed for XML.

Enter Visitor:
function visit(aTree, anAcceptor, aVisitProcessor)

I proceed from the assumption:
- 90% tasks are based on search by equals or like.
- 10% tasks can be realized by custom "acceptor" and/or custom "visit
processor"

Moreover, Visitor allowed to modify tree so well as search from them.
For example, I can design code, that removed from JSON data structure
all persons whose birth day arrived on full Moon (20 lines of code).

Java Visitor on Tree vs. Events named Digester
http://jakarta.apache.org/commons/digester/

Resume:
Of course Visitor is not competed with SQL (especially on server with
indexes, cache etc), Visitor is not a rival for XPATH on XML.

TrimQuery solution is very good and very helpful, but for JSON
JsonTools is preffered more...
http://sourceforge.net/projects/jsontools.

Regards, Alexey Luchkovsky

--- In json@yahoogroups.com, "Anand Sadasivam" <anand.sadasivam@...>
wrote:
>
> Hi,
>
> Check out this...
>
> http://trimpath.com/project/wiki/TrimQuery
>
> you can see the demo right here...
> http://trimpath.com/demos/test1/trimpath/query_demo.html .
>
>
> Hope this helps.
>
> Regards,
> Anand.S
>
>
> On 2/26/07, Alexey Luchkovsky <luchkovsky@...> wrote:
> >
> >   --- In json@yahoogroups.com <json%40yahoogroups.com>,
"george.jempty" <
> > george.jempty@> wrote:
> > >
> > > --- In json@yahoogroups.com <json%40yahoogroups.com>, "Matthew
Morley"
> > <WickedLogic@> wrote:
> > > > If you are working in an environment where the JSON consumer
is a web
> > > > browser, let the server do the heavy lifting and pass you the
> > > matches. If
> > > > you really need the local ability to search or are doing
non-browser
> > > > exchanges, I am sure there exists generic functions to search
> > > through sets
> > > > of data and match criteria. The real question is which language
> > you are
> > > > doing it in, and is it worth the overhead and complication.
> > >
> > > Baloney. The real question is the OP's original question: "Has
anyone
> > > played with a way to find parts of a JSON structure like SQL?" This
> > > is not an unreasonable question: in fact its been considered by
> > > renowned Python/XML expert Uche Ogbuji; see
> > > http://copia.ogbuji.net/blog/2006-12-23/Why_JSON_v
> > > where he imagines "XQuery for JSON". By the way, a link to this very
> > > same article can be found at the bottom of json.org.
> > >
> >
> > JsonTools included solution for client lookup JSON data, you can find
> > parts of a JSON structure, if you need concrete decision, send
e-mail me.
> >
> >
> >
> >
>
>
>
> --
> Anand.S
> anand.sadasivam@...
> +91 99804 75305
>
>
> [Non-text portions of this message have been removed]
>

Hi,

i want to use JSON also with HTML snippets. The snippet has included
Smarty variables, i use the FCKeditor as wysiwyg-editor.
Firstly i found out that the quotation mark (") in the HTML snippet
will destroy the JSON encoded object. I read json.org, and i read the
control characters (",\,/ etc.) can not be unicode chars like all
other chars. But i trying to replace the control characters in the
json-wanted format (\",\\,\/ etc.) and it will not work :(

But when i replace only the quotation mark (") with the HTML code
" it will works:

replace(/"/g, "\"""); (client)
str_replace('"','"',$foo); (server)

Only with this change, i can send a little bit HTML code and smarty
variables (<b>{$foo}</b>,{if $bar}<i>{$bar}</i>{/if}).
It will works, but not fine!!!

Sometimes, when i send HTML snippets with this solution, it will
works, but sometime, i can't decode the JSON object.

Firstly i think, another character will destroy the JSON object like
the quotation mark (") before... I can't found another character, when
it sometimes works, and sometimes not works, with the same HTML
snippet...

I need also a solution for sending HTML code (or other programming
code, css, javascript etc.) with an JSON object for my AJAX application.

I like to know if there is any place from where i can download JSON
Parser.

Is there any place where i can put my xml and get JSON output online.

thanx

Rama

I've written an XSLT which allows you to go from XML to JSON while
still maintaining the ability to go back if you need to.  You can read
more about it here:

     http://jsonml.org/XML/

--- In json@yahoogroups.com, "rama_singh75" <rama_singh75@...> wrote:
>
> I like to know if there is any place from where i can download JSON
> Parser.
>
> Is there any place where i can put my xml and get JSON output online.
>
> thanx
>
> Rama
>

> I like to know if there is any place from where i can download JSON
> Parser.

There are many available at http://www.JSON.org/

I have been using json for quite some time now. But just recently, I was
starting a new project, and downloaded a new version of json.js from
www.json.org. The previous json framework that I used had no problem at all, but
I thought of upgrading. Changes includes the function calls , chaging
"stringify" to ".toJSONString". Now this is where I am having problems with. I
tried to create a json string out of  javascript object, and it gave me a "too
much recursion" error. What is this? how do I fix this ? would this mean that
the old json is better than the new one? I had no problems using the old one,
but it's just that the updated version seem to have a bug on this.

Here's a sample of what I did..


var jsonObj = {};
       jsonObj.name = "myname";
     jsonObj.email = "myemail"

alert ("TEST:" + jsonObj.toJSONString());

--------- NOW THIS WILL GIVE ME too much recursion .. HOW COME?

ROCK n ROLL REBEL






________________________________________________________________________________\
____
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html

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

--- In json@yahoogroups.com, Joshua Raphael Fuentes <joshuarpf@...> wrote:
>
> I have been using json for quite some time now. But just recently, I
was starting a new project, and downloaded a new version of json.js
from www.json.org. The previous json framework that I used had no
problem at all, but I thought of upgrading. Changes includes the
function calls , chaging "stringify" to ".toJSONString". Now this is
where I am having problems with. I tried to create a json string out
of  javascript object, and it gave me a "too much recursion" error.
What is this? how do I fix this ? would this mean that the old json is
better than the new one? I had no problems using the old one, but it's
just that the updated version seem to have a bug on this.
>
> Here's a sample of what I did..
>
>
> var jsonObj = {};
>       jsonObj.name = "myname";
>     jsonObj.email = "myemail"
>
> alert ("TEST:" + jsonObj.toJSONString());
>
> --------- NOW THIS WILL GIVE ME too much recursion .. HOW COME?

Premature standardization, that's how come.  See
http://javascript.crockford.com/remedial.html

--- In json@yahoogroups.com, Joshua Raphael Fuentes <joshuarpf@...> wrote:
>
> I have been using json for quite some time now. But just recently, I
was starting a new project, and downloaded a new version of json.js
from www.json.org. The previous json framework that I used had no
problem at all, but I thought of upgrading. Changes includes the
function calls , chaging "stringify" to ".toJSONString". Now this is
where I am having problems with. I tried to create a json string out
of  javascript object, and it gave me a "too much recursion" error.
What is this? how do I fix this ? would this mean that the old json is
better than the new one? I had no problems using the old one, but it's
just that the updated version seem to have a bug on this.
>
> Here's a sample of what I did..
>
>
> var jsonObj = {};
>       jsonObj.name = "myname";
>     jsonObj.email = "myemail"
>
> alert ("TEST:" + jsonObj.toJSONString());

I see this example working correctly on IE and Firefox.

JSON, by definition, does not serialize cyclical structures. Are you
attempting to serialize a cyclical structure, such as a DOM element?

Back in December, I co-authored an introductory article on JSON together with
Scott Mitchell [1]. I finally got news this week that it has gone live and
available over at:

http://msdn2.microsoft.com/en-us/library/bb299886.aspx

The article takes a cursory look at JSON, its origins and then its application
within JavaScript followed by C#. There won't much news in there for those who
have been working with JSON for a while now, but I wanted to nevertheless drop
this note in case future travelers come by looking to venture into this land.

Since someone considering JSON for the first time is always going to pop the
question about its merits over XML, we also included an objective comparison of
the two in a tabular fashion so that the reader can form a basis for his or her
decision. The direct link to the pertaining section is:

http://msdn2.microsoft.com/en-us/library/bb299886.aspx#intro_to_json_topic3

- Atif

[1] http://scottonwriting.net/sowblog/posts/11878.aspx




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

- A Sunday thought;

I was planning to tattoo "XML" on my left shoulder.

After I've discovered "JSON", all my data transfer formats became JSON instead
of XML. I'm confused, if I should tattoo JSON.
Which one's going to be there in the long term?

I know JSON is a data exchange format which makes it perfect for Web and XML is
a document format.

Which one would you tattoo on your shoulder?
My mind says, I should stick with XML, but I can't ignore JSON.

Are we gonna use JSON or XML in the next twenty years?

Mert

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

On 3/18/07, mertsakarya@... <mertsakarya@...> wrote:
>
>
>
>
>
>
> - A Sunday thought;
>
>  I was planning to tattoo "XML" on my left shoulder.
>
>  After I've discovered "JSON", all my data transfer formats became JSON
> instead of XML. I'm confused, if I should tattoo JSON.
>  Which one's going to be there in the long term?
>
>  I know JSON is a data exchange format which makes it perfect for Web and
> XML is a document format.
>
>  Which one would you tattoo on your shoulder?
>  My mind says, I should stick with XML, but I can't ignore JSON.
>
>  Are we gonna use JSON or XML in the next twenty years?
>
>  Mert
>
>  [Non-text portions of this message have been removed]
>
>

>  Which one's going to be there in the long term?

While XML and JSON are similar, JSON's biggest win is simplicity: it's
a convenient, well-supported serialization format that's great for
representing loosely-typed string/numeric values with two common data
structures found in most languages: hashes and arrays.  Plus
converting to/from JSON from/to native representation on many
languages can happen in a single step, usually (after the library's
loaded.)

XML has got a number years of maturity over JSON.  Widely-available
features XML has that JSON hasn't (or much of): DTDs, schemas,
validation, node attributes, and CDATA blocks, for starters.
Validation for JSON has come a long way in a short time, but it is far
from universal.  Validating data is usually up you, the developer, to
handle in the language you're converting JSON to/from.  The most you
can expect of any given JSON decoder is to tell you the JSON was
well-formed (i.e. whether or not it was unserialized, but not always
why it wasn't), and depending on the support for your language, you
might find a library that does schema-style validation.  The one thing
I worry about with JSON is vulnerabilities.

So maybe it is not for all purposes ... I'm guessing that people who
want the additional sophistication of XML will keep going with XML, at
least until JSON catches up.  As storage gets denser, bandwidth gets
faster, XML's higher calorie rating won't mean so much in future
years.  And not everybody wants to validate the data they receive, I
guess, so there's a place for both.  I'm thinking of data services
that want to provide data via light-weight, REST-y interfaces.

-kevin

Kevin Prichard
New York Times Digital
Lead Developer, MyTimes

On 3/18/07, mertsakarya@... <mertsakarya@...> wrote:
>
>
>
>
>
>
> - A Sunday thought;
>
>  I was planning to tattoo "XML" on my left shoulder.
>
>  After I've discovered "JSON", all my data transfer formats became JSON
> instead of XML. I'm confused, if I should tattoo JSON.
>  Which one's going to be there in the long term?
>
>  I know JSON is a data exchange format which makes it perfect for Web and
> XML is a document format.
>
>  Which one would you tattoo on your shoulder?
>  My mind says, I should stick with XML, but I can't ignore JSON.
>
>  Are we gonna use JSON or XML in the next twenty years?
>
>  Mert
>
>  [Non-text portions of this message have been removed]
>
>

Hi all,

     I have some questions regarding JSON but they are primarily to do
with RPC and serialization. I've noticed that there is a json-rpc group
too and am wondering whether these lists cooperate with each other and
whether RPC considerations ever feed back into the core definition of
JSON or simply rely on conventions to extend the format?

Thanks,
     Pete

The JSON.org page is now available in Russian.

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

Demos are online for pretty printing of JSON and schema validation of
JavaScript objects:

http://www.cerny-online.com/cerny.js/demos

Best regards,
Robert

My name is Pascal, and I'm the lead developer over at TwoLattes
(www.twolattes.com). We're
releasing a useful tool for AJAX oriented Java apps: JsonMarshaller.

In a few sentences, this projects allows programmers to describe Java entities
with simple
annotations and our framework marshalls and unmarshalls automatically. We work
hard to
make it as easy and transparent as possible!

The project's URL is

     http://code.twolattes.com/json

We hope it'll be usefull to others! Feedbacks welcome ;-)

thanks for the tip man.. but I just recently  noticed that it happens when I use
prototype.js from this scriptaculous framework. Right now, I am using the old
version of json.js, which didn't give me any problems at all.

have you tried using json.js with prototype.js? prototype.js is a cool framework
to use though

ROCK n ROLL REBEL


----- Original Message ----
From: george.jempty <george.jempty@...>
To: json@yahoogroups.com
Sent: Friday, March 16, 2007 6:30:21 PM
Subject: [json] Re: question json.js













             --- In json@yahoogroups. com, Joshua Raphael Fuentes <joshuarpf@.
..> wrote:

>

> I have been using json for quite some time now. But just recently, I

was starting a new project, and downloaded a new version of json.js

from www.json.org. The previous json framework that I used had no

problem at all, but I thought of upgrading. Changes includes the

function calls , chaging "stringify" to ".toJSONString" . Now this is

where I am having problems with. I tried to create a json string out

of  javascript object, and it gave me a "too much recursion" error.

What is this? how do I fix this ? would this mean that the old json is

better than the new one? I had no problems using the old one, but it's

just that the updated version seem to have a bug on this.

>

> Here's a sample of what I did..

>

>

> var jsonObj = {};

>       jsonObj.name = "myname";

>     jsonObj.email = "myemail"

>

> alert ("TEST:" + jsonObj.toJSONStrin g());

>

> --------- NOW THIS WILL GIVE ME too much recursion .. HOW COME?



Premature standardization, that's how come.  See

http://javascript. crockford. com/remedial. html














<!--

#ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean, sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean,
sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;}
#ygrp-vitnav{
padding-top:10px;font-family:Verdana;font-size:77%;margin:0;}
#ygrp-vitnav a{
padding:0 1px;}
#ygrp-actbar{
clear:both;margin:25px 0;white-space:nowrap;color:#666;text-align:right;}
#ygrp-actbar .left{
float:left;white-space:nowrap;}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;font-size:77%;padding:15px 0;}
#ygrp-ft{
font-family:verdana;font-size:77%;border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;}

#ygrp-vital{
background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;}
#ygrp-vital #vithd{
font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:upp\
ercase;}
#ygrp-vital ul{
padding:0;margin:2px 0;}
#ygrp-vital ul li{
list-style-type:none;clear:both;border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-ri\
ght:.5em;}
#ygrp-vital ul li .cat{
font-weight:bold;}
#ygrp-vital a {
text-decoration:none;}

#ygrp-vital a:hover{
text-decoration:underline;}

#ygrp-sponsor #hd{
color:#999;font-size:77%;}
#ygrp-sponsor #ov{
padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;margin:0;}
#ygrp-sponsor #ov li{
list-style-type:square;padding:6px 0;font-size:77%;}
#ygrp-sponsor #ov li a{
text-decoration:none;font-size:130%;}
#ygrp-sponsor #nc {
background-color:#eee;margin-bottom:20px;padding:0 8px;}
#ygrp-sponsor .ad{
padding:8px 0;}
#ygrp-sponsor .ad #hd1{
font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%\
;}
#ygrp-sponsor .ad a{
text-decoration:none;}
#ygrp-sponsor .ad a:hover{
text-decoration:underline;}
#ygrp-sponsor .ad p{
margin:0;}
o {font-size:0;}
.MsoNormal {
margin:0 0 0 0;}
#ygrp-text tt{
font-size:120%;}
blockquote{margin:0 0 0 4px;}
.replbq {margin:4;}
-->









________________________________________________________________________________\
____
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail

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

Hi,
i get data in JSON format, i want to validate or Parse my JSON data in
ruby.

can it be possible validate JSON data in ruby ?
is there any JSON parser for rubyonrail to parse JSON data.

I am wondering what people who know thieir json code make of this:

http://www.andyscott.id.au/index.cfm/2007/3/31/CFJsonService-01Alpha-Release

AN xml config file with the names of methods?

Is this bloat or not? Could there be some standard methods?

_________________________________________________________________
Advertisement: 10 Students. 1 Winner. You Decide
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fletsshop%2Ecom%2FCompetitions%2F\
LetsNetwork%2Ftabid%2F550%2FDefault%2Easpx&_t=754951090&_r=letsshop&_m=EXT

http://yuiblog.com/blog/2007/04/10/json-and-browser-security/

The JSON.org page is now available in Czech.

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

I was having a discussion with an implementer of a JSON library, and
over time the discussion boiled down to an argument over the
interpretation of one sentence in the RFC.  That sentence is the first
one in section "3. Encoding", to wit "JSON text SHALL be encoded in
Unicode."

Hopefully this will draw a response from Douglas Crockford, since it
may be that he is the only one that really knows what he meant by what
he said in the RFC.... but opinions from others are welcome.

The implementer claims that because Unicode is not a binary encoding,
but a set of codepoints, that this sentence means that Unicode
codepoints should be used in some manner to represent characters, but
that the bitstream that represents the JSON text could use escapes for
most of the characters (reducing the size of the character
repertoire), and then be encoded in, say, EBCDIC.  While it is
possible to conceive of doing such a thing, I question if his
interpretation is valid.

My interpretation of that same sentence is that the character codes
should indeed be Unicode codepoints, and in addition, they should be
encoded in one of the 5 UTF-* Unicode encodings listed later in the
same section.  Clearly by using escapes, it is possible to reduce the
character repertoire to ASCII, or even a subset of ASCII, but ASCII is
a subset of Unicode's UTF-8 encoding, so that is valid.

So I'd welcome interpretations on exactly what encodings are legal
JSON texts.

Some following questions are:

1) Must a conformant JSON parser recognize all legal encodings?  Or
can a parser be conformant with documented restrictions on what
encodings it can accept?

2) Is a conformant JSON generator allowed to have options to generate
text that is not quite JSON conformant?  Or must it be completely
limited to producing JSON legal JSON text only?

--- In json@yahoogroups.com, "json_is_clever" <vendor@...> wrote:

> The implementer claims that because Unicode is not a binary encoding,
> but a set of codepoints, that this sentence means that Unicode
> codepoints should be used in some manner to represent characters, but
> that the bitstream that represents the JSON text could use escapes for
> most of the characters (reducing the size of the character
> repertoire), and then be encoded in, say, EBCDIC.  While it is
> possible to conceive of doing such a thing, I question if his
> interpretation is valid.

No, that is a wild misreading of the RFC. The JSON text must be
represented in Unicode, and the preferred encoding is UTF-8.

> 1) Must a conformant JSON parser recognize all legal encodings?  Or
> can a parser be conformant with documented restrictions on what
> encodings it can accept?

Parties can agree on what is acceptable and meaningful. For example,
it is reasonable for a receiver to put limits on message length or
string length or nesting depth.

> 2) Is a conformant JSON generator allowed to have options to generate
> text that is not quite JSON conformant?  Or must it be completely
> limited to producing JSON legal JSON text only?

A JSON generator may only produce valid JSON text.

I have one more question, do I need to convert unicode characters to
something like "\u12345"?

Michael


On 13 Apr 2007 15:47:13 -0700, Douglas Crockford <douglas@...>
wrote:
>
>   --- In json@yahoogroups.com <json%40yahoogroups.com>, "json_is_clever"
> <vendor@...> wrote:
>
> > The implementer claims that because Unicode is not a binary encoding,
> > but a set of codepoints, that this sentence means that Unicode
> > codepoints should be used in some manner to represent characters, but
> > that the bitstream that represents the JSON text could use escapes for
> > most of the characters (reducing the size of the character
> > repertoire), and then be encoded in, say, EBCDIC. While it is
> > possible to conceive of doing such a thing, I question if his
> > interpretation is valid.
>
> No, that is a wild misreading of the RFC. The JSON text must be
> represented in Unicode, and the preferred encoding is UTF-8.
>
> > 1) Must a conformant JSON parser recognize all legal encodings? Or
> > can a parser be conformant with documented restrictions on what
> > encodings it can accept?
>
> Parties can agree on what is acceptable and meaningful. For example,
> it is reasonable for a receiver to put limits on message length or
> string length or nesting depth.
>
> > 2) Is a conformant JSON generator allowed to have options to generate
> > text that is not quite JSON conformant? Or must it be completely
> > limited to producing JSON legal JSON text only?
>
> A JSON generator may only produce valid JSON text.
>
>
>


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

Douglas Crockford wrote:
>> 1) Must a conformant JSON parser recognize all legal encodings?  Or
>> can a parser be conformant with documented restrictions on what
>> encodings it can accept?
>
> Parties can agree on what is acceptable and meaningful. For example,
> it is reasonable for a receiver to put limits on message length or
> string length or nesting depth.

For example, JSON in E-0.9 accepts only Unicode characters from the "basic
multilingual plane", i.e., characters whose code point fits in 16 bits. As I
read the JSON spec, this is an allowable restriction. This restriction is
needed since E-0.9 does not support Unicode supplementary characters, i.e.,
characters whose code points are >= 2**16.

--
Text by me above is hereby placed in the public domain

      Cheers,
      --MarkM

--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

> No, that is a wild misreading of the RFC. The JSON text must be
> represented in Unicode, and the preferred encoding is UTF-8.

Thanks for the clarification, Douglas.

--- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
wrote:
>
> I have one more question, do I need to convert unicode characters to
> something like "\u12345"?

No. The \u notation is only required for some of the control characters.

Hi,

currently I have only something like \r, \n or \t, are those chars
allowed? Which control chars are you talking about? Thanks a lot.

Michael



On 14 Apr 2007 06:45:58 -0700, Douglas Crockford <douglas@...> wrote:
> --- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
> wrote:
> >
> > I have one more question, do I need to convert unicode characters to
> > something like "\u12345"?
>
> No. The \u notation is only required for some of the control characters.
>
>


--
Best regards | Schöne Grüße
Michael

Microsoft MVP - Most Valuable Professional
Microsoft MCAD - Certified Application Developer

http://weblogs.asp.net/mschwarz/
http://www.ajaxpro.info/

WPF/E: http://groups.google.com/group/wpf-everywhere

Skype: callto:schwarz-interactive
MSN IM: passport@...

--- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
wrote:

> currently I have only something like \r, \n or \t, are those chars
> allowed? Which control chars are you talking about? Thanks a lot.

None of the control characters can appear in JSON strings. You can use
the \u convention to represent them. A few of them, such as linefeed
and tab, have more compact representations such as \n and \t. Take
your pick.

The JSON.org page is now available in Arabic.

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