I have a string containing a single \ character. I'm not quite sure
what this string should look like once json encoded. My javascript
encoder (a popular one) is giving me `\\\\` ? Shouldn't the correct
encoding be `\\`?

--
Matt

--- In json@yahoogroups.com, "mpcmtechnologies" <WickedLogic@g...> wrote:
> I have a string containing a single \ character. I'm not quite sure
> what this string should look like once json encoded. My javascript
> encoder (a popular one) is giving me `\\\\` ? Shouldn't the correct
> encoding be `\\`?

No, it should be "\\". JSON does not use the ` character.

On 7/19/05, Douglas Crockford <douglas@...> wrote:
>  No, it should be "\\". JSON does not use the ` character.

Sorry, I have a value of \ and it is encoding it to \\\\. The
backticks where added to show that that was the value. Sorry for the
confusion.

The parser I am using is the javascript one provided via your site,
[http://www.crockford.com/JSON/json.js].

Strange, I just tried to generate a test and could not get it to
repeat what I felt was wrong encoding... must have been something in
my code. I'll post a follow up if I am able to reproduce it tomorrow
at work.

Thank you for setting up these groups and hosting the json site. It
really is much more fun than xml-rpc.

--
Matthew P. C. Morley

So how does this JSON thing compare to this:

http://microformats.org/

Inquiring minds want to know.

Well what I would say is:

-          microformats are xHTML tags - intended on providing standards for
new forms of structured data

-          JSON = I haven't the foggiest - just got here (common data
interchange verbs?) (OpenAPIs???)



What IS JSON?



   _____

From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of Roland
H. Alden
Sent: Wednesday, July 20, 2005 2:26 PM
To: json@yahoogroups.com
Subject: [json] json



So how does this JSON thing compare to this:

http://microformats.org/

Inquiring minds want to know.




   _____

YAHOO! GROUPS LINKS



*  Visit your group "json <http://groups.yahoo.com/group/json> " on
the web.

*  To unsubscribe from this group, send an email to:
  json-unsubscribe@yahoogroups.com
<mailto:json-unsubscribe@yahoogroups.com?subject=Unsubscribe>

*  Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service.



   _____



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

> So how does this JSON thing compare to this:
>
> http://microformats.org/
>
> Inquiring minds want to know.

Completely unrelated.

JSON is a data encoding standard, while Microformats are an attempt
to formalize certain common types of meaningful information (event
listings, contact information, "tags", etc.) into HTML readable by
people and machines.

-mike.

------------------------------------------------------
michal migurski- contact info, blog, and pgp key:
sf/ca            http://mike.teczno.com/contact.html

--- In json@yahoogroups.com, "Roland H. Alden" <ralden@r...> wrote:
> So how does this JSON thing compare to this:
>
> http://microformats.org/
>
> Inquiring minds want to know.

microformats is layered on top of XML. JSON could replace the XML
layer. JSON is used to represent values (string, numbers, booleans,
null) in sequences (aka arrays) and collections of name/value pairs
(aka objects).

> microformats is layered on top of XML. JSON could replace the XML
> layer. JSON is used to represent values (string, numbers, booleans,
> null) in sequences (aka arrays) and collections of name/value pairs
> (aka objects).

How is it compared to ASN.1?

What's "JSON" stand for?

--- In json@yahoogroups.com, "Roland H. Alden" <ralden@r...> wrote:

> How is it compared to ASN.1?

It is considerably simpler. It is described at http://www.JSON.org

> What's "JSON" stand for?

JavaScript Object Notation.

"Roland H. Alden" <ralden@...> writes:

>> microformats is layered on top of XML. JSON could replace the XML
>> layer. JSON is used to represent values (string, numbers, booleans,
>> null) in sequences (aka arrays) and collections of name/value pairs
>> (aka objects).
>
> How is it compared to ASN.1?

It's quite a long way from ASN.1. ASN.1 is a data definition language
(a schema language if you like).

JSON is a data format.


ASN.1 is like XML-Schema and JSON is like XML.


> What's "JSON" stand for?

Top search on google tells you:

   Introducing JSON
   JSON (JavaScript Object Notation) is a lightweight data-interchange
   format. ... These properties make JSON an ideal data-interchange
   language. ...
   www.json.org/ - 7k - Cached - Similar pages



Nic Ferrier
http://www.tapsellferrier.co.uk

I want to build a web application where the responses to requests will
be in JSON or at some point in time in a different format (e.g. XML).
HTTP does allow the client to state a preference for a certain
representation of a resource by sending the header field "Accept". The
value of the field is a media range which can be as narrow as one
media type (e.g. "text/html"). I think using "Accept" to state the
client's wish for a JSON representation of the resource would be
appropriate. Does anyone disagree?

Further, what is the media type of JSON? Is there already a standard
mime type for JSON? If not, how do we get one and what should it be?

Robert.

It would seem text/json is what it should be and I believe there is a
documented registration process at IANA.


> -----Original Message-----
> From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
> Robert Cerny
> Sent: Tuesday, July 26, 2005 1:56 AM
> To: json@yahoogroups.com
> Subject: [json] Media type for JSON?
>
> I want to build a web application where the responses to requests will
> be in JSON or at some point in time in a different format (e.g. XML).
> HTTP does allow the client to state a preference for a certain
> representation of a resource by sending the header field "Accept". The
> value of the field is a media range which can be as narrow as one
> media type (e.g. "text/html"). I think using "Accept" to state the
> client's wish for a JSON representation of the resource would be
> appropriate. Does anyone disagree?
>
> Further, what is the media type of JSON? Is there already a standard
> mime type for JSON? If not, how do we get one and what should it be?
>
> Robert.
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

On 7/26/05, Roland H. Alden <ralden@...> wrote:
> It would seem text/json is what it should be and I believe there is a
> documented registration process at IANA.

No, I don't think so. Note that text/javascript and text/ecmascript
are obsolete, and replaced by application/javascript and
application/ecmascript respectively. See:

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&filename=draft\
-hoehrmann-script-types

Therefore, any media type registered for JSON would likely be application/json.

--
Martin Cooper


> > -----Original Message-----
> > From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
> > Robert Cerny
> > Sent: Tuesday, July 26, 2005 1:56 AM
> > To: json@yahoogroups.com
> > Subject: [json] Media type for JSON?
> >
> > I want to build a web application where the responses to requests will
> > be in JSON or at some point in time in a different format (e.g. XML).
> > HTTP does allow the client to state a preference for a certain
> > representation of a resource by sending the header field "Accept". The
> > value of the field is a media range which can be as narrow as one
> > media type (e.g. "text/html"). I think using "Accept" to state the
> > client's wish for a JSON representation of the resource would be
> > appropriate. Does anyone disagree?
> >
> > Further, what is the media type of JSON? Is there already a standard
> > mime type for JSON? If not, how do we get one and what should it be?
> >
> > Robert.
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

> Therefore, any media type registered for JSON would likely be
> application/json.

You would seem to be correct assuming RFC 2046 is the controlling
standard. Quoting from that:

4.5.  Application Media Type

    The "application" media type is to be used for discrete data which do
    not fit in any of the other categories, and particularly for data to
    be processed by some type of application program.  This is
    information which must be processed by an application before it is
    viewable or usable by a user.  Expected uses for the "application"
    media type include file transfer, spreadsheets, data for mail-based
    scheduling systems, and languages for "active" (computational)
    material.  (The latter, in particular, can pose security problems
    which must be understood by implementors, and are considered in
    detail in the discussion of the "application/PostScript" media type.)

Roland H. Alden wrote:
>>Therefore, any media type registered for JSON would likely be
>>application/json.
>
>
> You would seem to be correct assuming RFC 2046 is the controlling
> standard. Quoting from that:
>
> 4.5.  Application Media Type
>
>    The "application" media type is to be used for discrete data which do
>    not fit in any of the other categories, and particularly for data to
>    be processed by some type of application program.  This is
>    information which must be processed by an application before it is
>    viewable or usable by a user.


What are the media types for html and xml?


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

      Cheers,
      --MarkM

On 7/26/05, Mark Miller <markm@...> wrote:
> Roland H. Alden wrote:
> >>Therefore, any media type registered for JSON would likely be
> >>application/json.
> >
> >
> > You would seem to be correct assuming RFC 2046 is the controlling
> > standard. Quoting from that:
> >
> > 4.5.  Application Media Type
> >
> >    The "application" media type is to be used for discrete data which do
> >    not fit in any of the other categories, and particularly for data to
> >    be processed by some type of application program.  This is
> >    information which must be processed by an application before it is
> >    viewable or usable by a user.
>
>
> What are the media types for html and xml?

Those are text/html and text/xml, respectively. See:

http://www.iana.org/assignments/media-types/

--
Martin Cooper


> --
> Text by me above is hereby placed in the public domain
>
>      Cheers,
>      --MarkM
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Martin Cooper wrote:
> On 7/26/05, Mark Miller <markm@...> wrote:
>
>>Roland H. Alden wrote:
>>
>>>>Therefore, any media type registered for JSON would likely be
>>>>application/json.
>>>
>>>
>>>You would seem to be correct assuming RFC 2046 is the controlling
>>>standard. Quoting from that:
>>>
>>>4.5.  Application Media Type
>>>
>>>   The "application" media type is to be used for discrete data which do
>>>   not fit in any of the other categories, and particularly for data to
>>>   be processed by some type of application program.  This is
>>>   information which must be processed by an application before it is
>>>   viewable or usable by a user.
>>
>>
>>What are the media types for html and xml?
>
>
> Those are text/html and text/xml, respectively. See:
>
> http://www.iana.org/assignments/media-types/


JSON is more like html & xml than it is like javascript. Therefore, reasoning
by precedent and analogy, I think the right answer is text/json.


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

      Cheers,
      --MarkM

Would someone shed some light on why the json.js file method of
detecting arrays was changed?

Array.prototype.______array = '______array'; is added

And
- if (arg.constructor == Array) {
+if (arg.______array == '______array') {

I can see that the array prototype is being extended to contain a
property to help identify object with that prototype, but it seems an
odd way to handle object type discovery (I don't know of another way).
It also threw warnings/errors when I swapped over to it, and have
swapped it back for now.

--
Matthew P. C. Morley

On 7/26/05, Mark Miller <markm@...> wrote:
> Martin Cooper wrote:
> > On 7/26/05, Mark Miller <markm@...> wrote:
> >
> >>Roland H. Alden wrote:
> >>
> >>>>Therefore, any media type registered for JSON would likely be
> >>>>application/json.
> >>>
> >>>
> >>>You would seem to be correct assuming RFC 2046 is the controlling
> >>>standard. Quoting from that:
> >>>
> >>>4.5.  Application Media Type
> >>>
> >>>   The "application" media type is to be used for discrete data which do
> >>>   not fit in any of the other categories, and particularly for data to
> >>>   be processed by some type of application program.  This is
> >>>   information which must be processed by an application before it is
> >>>   viewable or usable by a user.
> >>
> >>
> >>What are the media types for html and xml?
> >
> >
> > Those are text/html and text/xml, respectively. See:
> >
> > http://www.iana.org/assignments/media-types/
>
>
> JSON is more like html & xml than it is like javascript. Therefore, reasoning
> by precedent and analogy, I think the right answer is text/json.

I disagree that JSON is more like HTML and XML than like JavaScript,
particularly when it's specifically a subset of JavaScript.

Further, to quote some fragments from RFC 2046:

    (From section 4.1)
    The "text" media type is intended for sending material which is
    principally textual in form.
    [...]
    Beyond plain text, there are many formats for representing what might
    be known as "rich text".  An interesting characteristic of many such
    representations is that they are to some extent readable even without
    the software that interprets them.  It is useful, then, to
    distinguish them, at the highest level, from such unreadable data as
    images, audio, or text represented in an unreadable form. In the
    absence of appropriate interpretation software, it is reasonable to
    show subtypes of "text" to the user, while it is not reasonable to do
    so with most nontextual data. Such formatted textual data should be
    represented using subtypes of "text".

I think it would be pretty hard to argue that JSON is "rich text", or
that it would be reasonable to show JSON code directly to the user.

    (From section 4.5)
    The "application" media type is to be used for discrete data which do
    not fit in any of the other categories, and particularly for data to
    be processed by some type of application program.  This is
    information which must be processed by an application before it is
    viewable or usable by a user.  Expected uses for the "application"
    media type include file transfer, spreadsheets, data for mail-based
    scheduling systems, and languages for "active" (computational)
    material.  (The latter, in particular, can pose security problems
    which must be understood by implementors, and are considered in
    detail in the discussion of the "application/PostScript" media type.)

IMO, this explains rather well the usage of JSON. It certainly seems
much more appropriate to me than a "text" media type.

--
Martin Cooper


> --
> Text by me above is hereby placed in the public domain
>
>      Cheers,
>      --MarkM
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Has anyone successfully used JSON with ColdFusion?

I'm debating on whether I should use it or not...

thanks,
-Amy

Martin Cooper wrote:
>
>    (From section 4.1)
>    The "text" media type is intended for sending material which is
>    principally textual in form.
>    [...]
>    Beyond plain text, there are many formats for representing what might
>    be known as "rich text".  An interesting characteristic of many such
>    representations is that they are to some extent *readable* even without
>    the software that interprets them. [Emphasis added]
>
> I think it would be pretty hard to argue that JSON is "rich text", or
> that it would be reasonable to show JSON code directly to the user.

By what stretch of the imagination is xml readable?

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

      Cheers,
      --MarkM

--- In json@yahoogroups.com, "ldyhwke24" <ldyhwke24@y...> wrote:
> Has anyone successfully used JSON with ColdFusion?
>
> I'm debating on whether I should use it or not...

I haven't tried it yet, but near the bottom of the JSON home page
(http://json.org) is a link to "JSON in ColdFusion", so there seems to
be a ColdFusion implementation.  Also, considering ColdFusion is
implemented in Java anymore, you might also check out "JSON in Java",
an implementation by JSON's inventor himself, Douglas Crockford.

Let us know how it goes

George Jempty
http://htmatters.net (http://jemptymethod.com coming soon)

I just got it to work this morning.  I'm using CFJSON on the ColdFusion end..
and JSON on the javascript..  it seems to work out pretty well.

I wasn't quite sure if I'd need it, turns out I did.


jemptymethod <jemptymethod@...> wrote:
--- In json@yahoogroups.com, "ldyhwke24" <ldyhwke24@y...> wrote:
> Has anyone successfully used JSON with ColdFusion?
>
> I'm debating on whether I should use it or not...

I haven't tried it yet, but near the bottom of the JSON home page
(http://json.org) is a link to "JSON in ColdFusion", so there seems to
be a ColdFusion implementation.  Also, considering ColdFusion is
implemented in Java anymore, you might also check out "JSON in Java",
an implementation by JSON's inventor himself, Douglas Crockford.

Let us know how it goes

George Jempty
http://htmatters.net (http://jemptymethod.com coming soon)





SPONSORED LINKS
Json Programming languages Format Computer security Computer training Large
format

---------------------------------
YAHOO! GROUPS LINKS


     Visit your group "json" on the web.

     To unsubscribe from this group, send an email to:
  json-unsubscribe@yahoogroups.com

     Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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

--- In json@yahoogroups.com, Amy <ldyhwke24@y...> wrote:
> I just got it to work this morning.  I'm using CFJSON on the
ColdFusion end.. and JSON on the javascript..  it seems to work out
pretty well.

Excellent.  I'm the hotscripts.com newsletter columnist for both
Javascript and ColdFusion, by the way, and I think it might be
interesting to write about CFJSON one month.  So please, if it's not
too much to ask, let me know any kind of special insight you gain.

George Jempty
http://htmatters.net (http://jemptymethod.com coming soon)

> > JSON is more like html & xml than it is like javascript.
> > Therefore, reasoning by precedent and analogy,
> > I think the right answer is text/json.

> I disagree that JSON is more like HTML and XML than like JavaScript,
> particularly when it's specifically a subset of JavaScript.

I agree with MarkM on this one. JSON is not JavaScript. While it is a
subset of JavaScript, its usage patterns are radically different. I
think the right answer is text/json.

On 7/29/05, Douglas Crockford <douglas@...> wrote:
> > > JSON is more like html & xml than it is like javascript.
> > > Therefore, reasoning by precedent and analogy,
> > > I think the right answer is text/json.
>
> > I disagree that JSON is more like HTML and XML than like JavaScript,
> > particularly when it's specifically a subset of JavaScript.
>
> I agree with MarkM on this one. JSON is not JavaScript. While it is a
> subset of JavaScript, its usage patterns are radically different. I
> think the right answer is text/json.

The usage patterns may be different, but if you read the portions of
RFC 2046 that I quoted, those usage patterns still match
application/json much better than text/json.

--
Martin Cooper


>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Martin Cooper wrote:
> The usage patterns may be different, but if you read the portions of
> RFC 2046 that I quoted, those usage patterns still match
> application/json much better than text/json.


By the criteria you quoted, xml should be application/xml.


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

      Cheers,
      --MarkM

On 7/29/05, Mark Miller <markm@...> wrote:
> Martin Cooper wrote:
> > The usage patterns may be different, but if you read the portions of
> > RFC 2046 that I quoted, those usage patterns still match
> > application/json much better than text/json.
>
>
> By the criteria you quoted, xml should be application/xml.

So? We're talking about JSON, not XML. Finding an example for which
you disagree with the existing categorisation isn't much of a reason
to not follow the spec when looking for the right categorisation for
JSON.

--
Martin Cooper


>
> --
> Text by me above is hereby placed in the public domain
>
>      Cheers,
>      --MarkM
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hi,

Shouldn't it be possible to jsonize a string like this?

{"doubleQuoteSurroundedBySpaces":"   \"    "}}'

json.py and json.js both choke when trying to parse this

SingleQuotes are OK
o=JSON.parse('{"a":" \' "}')
[object Object]
o.toSource()
({a:" ' "})

However...
o=JSON.parse('{"a":" \" "}')
JSONError: Bad object

Is there no way to express the valid object {a:'"'}?

jonschull5 wrote:
> Hi,
>
> Shouldn't it be possible to jsonize a string like this?
>
> {"doubleQuoteSurroundedBySpaces":"   \"    "}}'


Assuming your closing ")'" is an error, E's embedded term-tree language
(<http://www.erights.org/data/terml/index.html>) accepts this just fine:

      ? term`{"doubleQuoteSurroundedBySpaces":"   \"    "}`
      # value: term`{"doubleQuoteSurroundedBySpaces": "   \"    "}`

We altered E's term-tree language to be a superset of JSON. Shown above is a
command-line interaction with the E interpreter. "? " is E's prompt. ("> " is
E's continuation prompt, and is not shown here.) The text to the right of the
"? " is an E expression entered by the user. The expression shown above is a
quasi-literal expression, consisting of the name of the quasi-parser to the
left of the back-tick, and the quasi-literal string to be parsed within the
back-ticks. In this case we're just using it as a parser. To better see what's
going on, below we invoke E's term-tree parser explicitly on your JSON string:

      ? def str := `{"doubleQuoteSurroundedBySpaces":"   \"    "}`
      # value: "{\"doubleQuoteSurroundedBySpaces\":\"   \\\"    \"}"

      ? def termParser := <import:org.quasiliteral.term.TermParser>
      # value: <makeTermParser>

      ? def tt := termParser(str)
      # value: term`{"doubleQuoteSurroundedBySpaces": "   \"    "}`

We can use a quasi-literal pattern to pattern match this tree and extract its
components. The text between the "@{" and "}" is a pattern in the E
programming language. Whatever the term-tree quasi-literal pattern extracts at
that position is matched against this E pattern, which in this case just
coerces and binds variables k and v.

Since both E and the term-tree language use ":", but for two quite different
purposes, our convention is to put a space to the left of an E ":" but a space
to the right of a term-tree colon.

      ? def term`{@{k :String}: @{v :String}}` := tt
      # value: term`{"doubleQuoteSurroundedBySpaces": "   \"    "}`

      ? k
      # value: "doubleQuoteSurroundedBySpaces"

      ? v
      # value: "   \"    "

For more, see <http://www.erights.org/elang/quasi/terms/like-ellipses.html>
and the section "Quasi-JSON back from the dead" at
<http://www.eros-os.org/pipermail/e-lang/2005-May/010646.html>.

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

      Cheers,
      --MarkM