Andrew Faulds scripsit:

> For configs I ask, why not just use Microsoft's Initialisation file format
> (.ini)? It's limited, sure, you only have 1 level of depth, but it's fine
> for most things.

Actually, multiple levels are permitted by convention.  If the name inside
the brackets has backslashes in it, it is interpreted as a multi-level name.

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

I meant that you can't really nest things (although theoretically you could
put an INI file as a string, but it's unwieldy)

On 10 July 2012 22:27, John Cowan <cowan@...> wrote:

> **
>
>
> Andrew Faulds scripsit:
>
>
> > For configs I ask, why not just use Microsoft's Initialisation file
> format
> > (.ini)? It's limited, sure, you only have 1 level of depth, but it's fine
> > for most things.
>
> Actually, multiple levels are permitted by convention. If the name inside
> the brackets has backslashes in it, it is interpreted as a multi-level
> name.
>
> --
> 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
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

I agree filtering makes sense, but why run it through a full-blown filter when
all I want is to support comments? I think this is a nice efficient and simple
tool for just removing comments: https://github.com/kitcambridge/json-compressor

I'm thinking of using that as the main way and only using my custom jison parser
when I want to give detailed error messages.

Also a main goal I have is to get it to work in multiple programming languages.
Most of my test suite is JSON - it just has a tiny runner that iterates through
the test data, so that makes it easy to port. Having a native version could make
it easier for users of the other languages.

Ben

--- In json@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> >
> > The standard is respected in most places. Try adding comments and then using
a common JSON parser (like the one in Firefox or Chrome) and you'll see an
error. Because of that, it's foolish to output JSON that doesn't conform to the
spec.
> >
> > I'm not especially interested in the three changes in the original thread.
What I do find interesting is comment support. JSON is so nice and simple that
it's often being used for configuration and not just serialization. In many
cases, comments are more useful than problematic in configuration files. For
this reason I'm working on making a standard format that is simply
JSON+comments, and I'm calling it Eon (EcmaScript Object Notation). I think if
you're going to try to come up with your own JSON-like format, you should come
up with a file extension and content-type that doesn't contain "json". Some HTTP
client libraries will try to parse everything that has the substring "json" in
its content type, and it's best not to break those, even though they should
arguably be checking for word boundaries.
>
>
> You don't need a new standard. Just pipe JSMin in front of your JSON parser.
>

JSMin isn't a full-blown filter, it relies on valid JS/JSON being passed
in. pass in "b + ++a" and you'll get "b+++a" out.

On 10 July 2012 23:12, Ben Atkin <ben@...> wrote:

> **
>
>
> I agree filtering makes sense, but why run it through a full-blown filter
> when all I want is to support comments? I think this is a nice efficient
> and simple tool for just removing comments:
> https://github.com/kitcambridge/json-compressor
>
> I'm thinking of using that as the main way and only using my custom jison
> parser when I want to give detailed error messages.
>
> Also a main goal I have is to get it to work in multiple programming
> languages. Most of my test suite is JSON - it just has a tiny runner that
> iterates through the test data, so that makes it easy to port. Having a
> native version could make it easier for users of the other languages.
>
> Ben
>
> --- In json@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> >
> > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > >
> > > The standard is respected in most places. Try adding comments and then
> using a common JSON parser (like the one in Firefox or Chrome) and you'll
> see an error. Because of that, it's foolish to output JSON that doesn't
> conform to the spec.
> > >
> > > I'm not especially interested in the three changes in the original
> thread. What I do find interesting is comment support. JSON is so nice and
> simple that it's often being used for configuration and not just
> serialization. In many cases, comments are more useful than problematic in
> configuration files. For this reason I'm working on making a standard
> format that is simply JSON+comments, and I'm calling it Eon (EcmaScript
> Object Notation). I think if you're going to try to come up with your own
> JSON-like format, you should come up with a file extension and content-type
> that doesn't contain "json". Some HTTP client libraries will try to parse
> everything that has the substring "json" in its content type, and it's best
> not to break those, even though they should arguably be checking for word
> boundaries.
> >
> >
> > You don't need a new standard. Just pipe JSMin in front of your JSON
> parser.
> >
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

Thanks for pointing that out.

That reminds me - another thing I want is to be able to automatically change
something in an eon file without stripping out comments or whitespace or
changing the order of things. This will require a parser of sorts and not just a
minifying step.

Ben

--- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
>
> JSMin isn't a full-blown filter, it relies on valid JS/JSON being passed
> in. pass in "b + ++a" and you'll get "b+++a" out.
>
> On 10 July 2012 23:12, Ben Atkin <ben@...> wrote:
>
> > **
> >
> >
> > I agree filtering makes sense, but why run it through a full-blown filter
> > when all I want is to support comments? I think this is a nice efficient
> > and simple tool for just removing comments:
> > https://github.com/kitcambridge/json-compressor
> >
> > I'm thinking of using that as the main way and only using my custom jison
> > parser when I want to give detailed error messages.
> >
> > Also a main goal I have is to get it to work in multiple programming
> > languages. Most of my test suite is JSON - it just has a tiny runner that
> > iterates through the test data, so that makes it easy to port. Having a
> > native version could make it easier for users of the other languages.
> >
> > Ben
> >
> > --- In json@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> >
> > >
> > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > >
> > > > The standard is respected in most places. Try adding comments and then
> > using a common JSON parser (like the one in Firefox or Chrome) and you'll
> > see an error. Because of that, it's foolish to output JSON that doesn't
> > conform to the spec.
> > > >
> > > > I'm not especially interested in the three changes in the original
> > thread. What I do find interesting is comment support. JSON is so nice and
> > simple that it's often being used for configuration and not just
> > serialization. In many cases, comments are more useful than problematic in
> > configuration files. For this reason I'm working on making a standard
> > format that is simply JSON+comments, and I'm calling it Eon (EcmaScript
> > Object Notation). I think if you're going to try to come up with your own
> > JSON-like format, you should come up with a file extension and content-type
> > that doesn't contain "json". Some HTTP client libraries will try to parse
> > everything that has the substring "json" in its content type, and it's best
> > not to break those, even though they should arguably be checking for word
> > boundaries.
> > >
> > >
> > > You don't need a new standard. Just pipe JSMin in front of your JSON
> > parser.
> > >
> >
> >
> >
>
>
>
> --
> Andrew Faulds (AJF)
> http://ajf.me/
>
>
> [Non-text portions of this message have been removed]
>

You don't want JSON, then. JSON isn't designed to update an existing file,
it deserialises and serialises.

On 10 July 2012 23:18, Ben Atkin <ben@...> wrote:

> **
>
>
> Thanks for pointing that out.
>
> That reminds me - another thing I want is to be able to automatically
> change something in an eon file without stripping out comments or
> whitespace or changing the order of things. This will require a parser of
> sorts and not just a minifying step.
>
> Ben
>
>
> --- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
> >
> > JSMin isn't a full-blown filter, it relies on valid JS/JSON being passed
> > in. pass in "b + ++a" and you'll get "b+++a" out.
> >
> > On 10 July 2012 23:12, Ben Atkin <ben@...> wrote:
> >
> > > **
>
> > >
> > >
> > > I agree filtering makes sense, but why run it through a full-blown
> filter
> > > when all I want is to support comments? I think this is a nice
> efficient
> > > and simple tool for just removing comments:
> > > https://github.com/kitcambridge/json-compressor
> > >
> > > I'm thinking of using that as the main way and only using my custom
> jison
> > > parser when I want to give detailed error messages.
> > >
> > > Also a main goal I have is to get it to work in multiple programming
> > > languages. Most of my test suite is JSON - it just has a tiny runner
> that
> > > iterates through the test data, so that makes it easy to port. Having a
> > > native version could make it easier for users of the other languages.
> > >
> > > Ben
> > >
> > > --- In json@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> > >
> > > >
> > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > >
> > > > > The standard is respected in most places. Try adding comments and
> then
> > > using a common JSON parser (like the one in Firefox or Chrome) and
> you'll
> > > see an error. Because of that, it's foolish to output JSON that doesn't
> > > conform to the spec.
> > > > >
> > > > > I'm not especially interested in the three changes in the original
> > > thread. What I do find interesting is comment support. JSON is so nice
> and
> > > simple that it's often being used for configuration and not just
> > > serialization. In many cases, comments are more useful than
> problematic in
> > > configuration files. For this reason I'm working on making a standard
> > > format that is simply JSON+comments, and I'm calling it Eon (EcmaScript
> > > Object Notation). I think if you're going to try to come up with your
> own
> > > JSON-like format, you should come up with a file extension and
> content-type
> > > that doesn't contain "json". Some HTTP client libraries will try to
> parse
> > > everything that has the substring "json" in its content type, and it's
> best
> > > not to break those, even though they should arguably be checking for
> word
> > > boundaries.
> > > >
> > > >
> > > > You don't need a new standard. Just pipe JSMin in front of your JSON
> > > parser.
> > > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Andrew Faulds (AJF)
> > http://ajf.me/
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

Which format should I use, then? XML?

http://www.coderanch.com/t/128908/XML/Preserve-comments-XSL

But I like JSON! Also these configs are going to get turned into a JSON
structure at some point, whether it's parsing eon, or converting eon to JSON
before parsing it.

Ben

--- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
>
> You don't want JSON, then. JSON isn't designed to update an existing file,
> it deserialises and serialises.
>
> On 10 July 2012 23:18, Ben Atkin <ben@...> wrote:
>
> > **
> >
> >
> > Thanks for pointing that out.
> >
> > That reminds me - another thing I want is to be able to automatically
> > change something in an eon file without stripping out comments or
> > whitespace or changing the order of things. This will require a parser of
> > sorts and not just a minifying step.
> >
> > Ben
> >
> >
> > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > >
> > > JSMin isn't a full-blown filter, it relies on valid JS/JSON being passed
> > > in. pass in "b + ++a" and you'll get "b+++a" out.
> > >
> > > On 10 July 2012 23:12, Ben Atkin <ben@> wrote:
> > >
> > > > **
> >
> > > >
> > > >
> > > > I agree filtering makes sense, but why run it through a full-blown
> > filter
> > > > when all I want is to support comments? I think this is a nice
> > efficient
> > > > and simple tool for just removing comments:
> > > > https://github.com/kitcambridge/json-compressor
> > > >
> > > > I'm thinking of using that as the main way and only using my custom
> > jison
> > > > parser when I want to give detailed error messages.
> > > >
> > > > Also a main goal I have is to get it to work in multiple programming
> > > > languages. Most of my test suite is JSON - it just has a tiny runner
> > that
> > > > iterates through the test data, so that makes it easy to port. Having a
> > > > native version could make it easier for users of the other languages.
> > > >
> > > > Ben
> > > >
> > > > --- In json@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> > > >
> > > > >
> > > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > > >
> > > > > > The standard is respected in most places. Try adding comments and
> > then
> > > > using a common JSON parser (like the one in Firefox or Chrome) and
> > you'll
> > > > see an error. Because of that, it's foolish to output JSON that doesn't
> > > > conform to the spec.
> > > > > >
> > > > > > I'm not especially interested in the three changes in the original
> > > > thread. What I do find interesting is comment support. JSON is so nice
> > and
> > > > simple that it's often being used for configuration and not just
> > > > serialization. In many cases, comments are more useful than
> > problematic in
> > > > configuration files. For this reason I'm working on making a standard
> > > > format that is simply JSON+comments, and I'm calling it Eon (EcmaScript
> > > > Object Notation). I think if you're going to try to come up with your
> > own
> > > > JSON-like format, you should come up with a file extension and
> > content-type
> > > > that doesn't contain "json". Some HTTP client libraries will try to
> > parse
> > > > everything that has the substring "json" in its content type, and it's
> > best
> > > > not to break those, even though they should arguably be checking for
> > word
> > > > boundaries.
> > > > >
> > > > >
> > > > > You don't need a new standard. Just pipe JSMin in front of your JSON
> > > > parser.
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Andrew Faulds (AJF)
> > > http://ajf.me/
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
>
> --
> Andrew Faulds (AJF)
> http://ajf.me/
>
>
> [Non-text portions of this message have been removed]
>

Don't complain that JSON isn't what you want it to be. There are plenty of
alternative formats, use one of them, instead.

On 10 July 2012 23:39, Ben Atkin <ben@...> wrote:

> **
>
>
> Which format should I use, then? XML?
>
> http://www.coderanch.com/t/128908/XML/Preserve-comments-XSL
>
> But I like JSON! Also these configs are going to get turned into a JSON
> structure at some point, whether it's parsing eon, or converting eon to
> JSON before parsing it.
>
>
> Ben
>
> --- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
> >
> > You don't want JSON, then. JSON isn't designed to update an existing
> file,
> > it deserialises and serialises.
> >
> > On 10 July 2012 23:18, Ben Atkin <ben@...> wrote:
> >
> > > **
>
> > >
> > >
> > > Thanks for pointing that out.
> > >
> > > That reminds me - another thing I want is to be able to automatically
> > > change something in an eon file without stripping out comments or
> > > whitespace or changing the order of things. This will require a parser
> of
> > > sorts and not just a minifying step.
> > >
> > > Ben
> > >
> > >
> > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > >
> > > > JSMin isn't a full-blown filter, it relies on valid JS/JSON being
> passed
> > > > in. pass in "b + ++a" and you'll get "b+++a" out.
> > > >
> > > > On 10 July 2012 23:12, Ben Atkin <ben@> wrote:
> > > >
> > > > > **
> > >
> > > > >
> > > > >
> > > > > I agree filtering makes sense, but why run it through a full-blown
> > > filter
> > > > > when all I want is to support comments? I think this is a nice
> > > efficient
> > > > > and simple tool for just removing comments:
> > > > > https://github.com/kitcambridge/json-compressor
> > > > >
> > > > > I'm thinking of using that as the main way and only using my custom
> > > jison
> > > > > parser when I want to give detailed error messages.
> > > > >
> > > > > Also a main goal I have is to get it to work in multiple
> programming
> > > > > languages. Most of my test suite is JSON - it just has a tiny
> runner
> > > that
> > > > > iterates through the test data, so that makes it easy to port.
> Having a
> > > > > native version could make it easier for users of the other
> languages.
> > > > >
> > > > > Ben
> > > > >
> > > > > --- In json@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> > > > >
> > > > > >
> > > > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > > > >
> > > > > > > The standard is respected in most places. Try adding comments
> and
> > > then
> > > > > using a common JSON parser (like the one in Firefox or Chrome) and
> > > you'll
> > > > > see an error. Because of that, it's foolish to output JSON that
> doesn't
> > > > > conform to the spec.
> > > > > > >
> > > > > > > I'm not especially interested in the three changes in the
> original
> > > > > thread. What I do find interesting is comment support. JSON is so
> nice
> > > and
> > > > > simple that it's often being used for configuration and not just
> > > > > serialization. In many cases, comments are more useful than
> > > problematic in
> > > > > configuration files. For this reason I'm working on making a
> standard
> > > > > format that is simply JSON+comments, and I'm calling it Eon
> (EcmaScript
> > > > > Object Notation). I think if you're going to try to come up with
> your
> > > own
> > > > > JSON-like format, you should come up with a file extension and
> > > content-type
> > > > > that doesn't contain "json". Some HTTP client libraries will try to
> > > parse
> > > > > everything that has the substring "json" in its content type, and
> it's
> > > best
> > > > > not to break those, even though they should arguably be checking
> for
> > > word
> > > > > boundaries.
> > > > > >
> > > > > >
> > > > > > You don't need a new standard. Just pipe JSMin in front of your
> JSON
> > > > > parser.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Andrew Faulds (AJF)
> > > > http://ajf.me/
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Andrew Faulds (AJF)
> > http://ajf.me/
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

Don't tell me what to do.

--- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
>
> Don't complain that JSON isn't what you want it to be. There are plenty of
> alternative formats, use one of them, instead.
>
> On 10 July 2012 23:39, Ben Atkin <ben@...> wrote:
>
> > **
> >
> >
> > Which format should I use, then? XML?
> >
> > http://www.coderanch.com/t/128908/XML/Preserve-comments-XSL
> >
> > But I like JSON! Also these configs are going to get turned into a JSON
> > structure at some point, whether it's parsing eon, or converting eon to
> > JSON before parsing it.
> >
> >
> > Ben
> >
> > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > >
> > > You don't want JSON, then. JSON isn't designed to update an existing
> > file,
> > > it deserialises and serialises.
> > >
> > > On 10 July 2012 23:18, Ben Atkin <ben@> wrote:
> > >
> > > > **
> >
> > > >
> > > >
> > > > Thanks for pointing that out.
> > > >
> > > > That reminds me - another thing I want is to be able to automatically
> > > > change something in an eon file without stripping out comments or
> > > > whitespace or changing the order of things. This will require a parser
> > of
> > > > sorts and not just a minifying step.
> > > >
> > > > Ben
> > > >
> > > >
> > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > >
> > > > > JSMin isn't a full-blown filter, it relies on valid JS/JSON being
> > passed
> > > > > in. pass in "b + ++a" and you'll get "b+++a" out.
> > > > >
> > > > > On 10 July 2012 23:12, Ben Atkin <ben@> wrote:
> > > > >
> > > > > > **
> > > >
> > > > > >
> > > > > >
> > > > > > I agree filtering makes sense, but why run it through a full-blown
> > > > filter
> > > > > > when all I want is to support comments? I think this is a nice
> > > > efficient
> > > > > > and simple tool for just removing comments:
> > > > > > https://github.com/kitcambridge/json-compressor
> > > > > >
> > > > > > I'm thinking of using that as the main way and only using my custom
> > > > jison
> > > > > > parser when I want to give detailed error messages.
> > > > > >
> > > > > > Also a main goal I have is to get it to work in multiple
> > programming
> > > > > > languages. Most of my test suite is JSON - it just has a tiny
> > runner
> > > > that
> > > > > > iterates through the test data, so that makes it easy to port.
> > Having a
> > > > > > native version could make it easier for users of the other
> > languages.
> > > > > >
> > > > > > Ben
> > > > > >
> > > > > > --- In json@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> > > > > >
> > > > > > >
> > > > > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > > > > >
> > > > > > > > The standard is respected in most places. Try adding comments
> > and
> > > > then
> > > > > > using a common JSON parser (like the one in Firefox or Chrome) and
> > > > you'll
> > > > > > see an error. Because of that, it's foolish to output JSON that
> > doesn't
> > > > > > conform to the spec.
> > > > > > > >
> > > > > > > > I'm not especially interested in the three changes in the
> > original
> > > > > > thread. What I do find interesting is comment support. JSON is so
> > nice
> > > > and
> > > > > > simple that it's often being used for configuration and not just
> > > > > > serialization. In many cases, comments are more useful than
> > > > problematic in
> > > > > > configuration files. For this reason I'm working on making a
> > standard
> > > > > > format that is simply JSON+comments, and I'm calling it Eon
> > (EcmaScript
> > > > > > Object Notation). I think if you're going to try to come up with
> > your
> > > > own
> > > > > > JSON-like format, you should come up with a file extension and
> > > > content-type
> > > > > > that doesn't contain "json". Some HTTP client libraries will try to
> > > > parse
> > > > > > everything that has the substring "json" in its content type, and
> > it's
> > > > best
> > > > > > not to break those, even though they should arguably be checking
> > for
> > > > word
> > > > > > boundaries.
> > > > > > >
> > > > > > >
> > > > > > > You don't need a new standard. Just pipe JSMin in front of your
> > JSON
> > > > > > parser.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andrew Faulds (AJF)
> > > > > http://ajf.me/
> > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Andrew Faulds (AJF)
> > > http://ajf.me/
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
>
> --
> Andrew Faulds (AJF)
> http://ajf.me/
>
>
> [Non-text portions of this message have been removed]
>

I'm not telling you what to do, I'm just saying that whining that a fixed
standard, which is designed for something different to what you want, does
not do what you want, is rather pointless.

On 10 July 2012 23:42, Ben Atkin <ben@...> wrote:

> **
>
>
> Don't tell me what to do.
>
>
> --- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
> >
> > Don't complain that JSON isn't what you want it to be. There are plenty
> of
> > alternative formats, use one of them, instead.
> >
> > On 10 July 2012 23:39, Ben Atkin <ben@...> wrote:
> >
> > > **
>
> > >
> > >
> > > Which format should I use, then? XML?
> > >
> > > http://www.coderanch.com/t/128908/XML/Preserve-comments-XSL
> > >
> > > But I like JSON! Also these configs are going to get turned into a JSON
> > > structure at some point, whether it's parsing eon, or converting eon to
> > > JSON before parsing it.
> > >
> > >
> > > Ben
> > >
> > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > >
> > > > You don't want JSON, then. JSON isn't designed to update an existing
> > > file,
> > > > it deserialises and serialises.
> > > >
> > > > On 10 July 2012 23:18, Ben Atkin <ben@> wrote:
> > > >
> > > > > **
> > >
> > > > >
> > > > >
> > > > > Thanks for pointing that out.
> > > > >
> > > > > That reminds me - another thing I want is to be able to
> automatically
> > > > > change something in an eon file without stripping out comments or
> > > > > whitespace or changing the order of things. This will require a
> parser
> > > of
> > > > > sorts and not just a minifying step.
> > > > >
> > > > > Ben
> > > > >
> > > > >
> > > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > > >
> > > > > > JSMin isn't a full-blown filter, it relies on valid JS/JSON being
> > > passed
> > > > > > in. pass in "b + ++a" and you'll get "b+++a" out.
> > > > > >
> > > > > > On 10 July 2012 23:12, Ben Atkin <ben@> wrote:
> > > > > >
> > > > > > > **
> > > > >
> > > > > > >
> > > > > > >
> > > > > > > I agree filtering makes sense, but why run it through a
> full-blown
> > > > > filter
> > > > > > > when all I want is to support comments? I think this is a nice
> > > > > efficient
> > > > > > > and simple tool for just removing comments:
> > > > > > > https://github.com/kitcambridge/json-compressor
> > > > > > >
> > > > > > > I'm thinking of using that as the main way and only using my
> custom
> > > > > jison
> > > > > > > parser when I want to give detailed error messages.
> > > > > > >
> > > > > > > Also a main goal I have is to get it to work in multiple
> > > programming
> > > > > > > languages. Most of my test suite is JSON - it just has a tiny
> > > runner
> > > > > that
> > > > > > > iterates through the test data, so that makes it easy to port.
> > > Having a
> > > > > > > native version could make it easier for users of the other
> > > languages.
> > > > > > >
> > > > > > > Ben
> > > > > > >
> > > > > > > --- In json@yahoogroups.com, "douglascrockford" <douglas@>
> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > > > > > >
> > > > > > > > > The standard is respected in most places. Try adding
> comments
> > > and
> > > > > then
> > > > > > > using a common JSON parser (like the one in Firefox or Chrome)
> and
> > > > > you'll
> > > > > > > see an error. Because of that, it's foolish to output JSON that
> > > doesn't
> > > > > > > conform to the spec.
> > > > > > > > >
> > > > > > > > > I'm not especially interested in the three changes in the
> > > original
> > > > > > > thread. What I do find interesting is comment support. JSON is
> so
> > > nice
> > > > > and
> > > > > > > simple that it's often being used for configuration and not
> just
> > > > > > > serialization. In many cases, comments are more useful than
> > > > > problematic in
> > > > > > > configuration files. For this reason I'm working on making a
> > > standard
> > > > > > > format that is simply JSON+comments, and I'm calling it Eon
> > > (EcmaScript
> > > > > > > Object Notation). I think if you're going to try to come up
> with
> > > your
> > > > > own
> > > > > > > JSON-like format, you should come up with a file extension and
> > > > > content-type
> > > > > > > that doesn't contain "json". Some HTTP client libraries will
> try to
> > > > > parse
> > > > > > > everything that has the substring "json" in its content type,
> and
> > > it's
> > > > > best
> > > > > > > not to break those, even though they should arguably be
> checking
> > > for
> > > > > word
> > > > > > > boundaries.
> > > > > > > >
> > > > > > > >
> > > > > > > > You don't need a new standard. Just pipe JSMin in front of
> your
> > > JSON
> > > > > > > parser.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Andrew Faulds (AJF)
> > > > > > http://ajf.me/
> > > > > >
> > > > > >
> > > > > > [Non-text portions of this message have been removed]
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Andrew Faulds (AJF)
> > > > http://ajf.me/
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Andrew Faulds (AJF)
> > http://ajf.me/
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

Thanks; I realize that, and also that since I'm the one making a file format I
should be more accepting of criticism.

But I don't mean to be whining. I see people using JSON for complex human-edited
configuration files, and it's a testament to how much nicer it is than XML and
more approachable it is than YAML. And for a lot of configuration formats,
comments aren't all that useful.

But some people really want traditional comments, and they are calling their
files with comments json. And this could break things. I'd like to provide an
alternative to call it something else so they'll know that it needs to be run
through a minifier before handing it off to a json parser.

Ben

--- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
>
> I'm not telling you what to do, I'm just saying that whining that a fixed
> standard, which is designed for something different to what you want, does
> not do what you want, is rather pointless.
>
> On 10 July 2012 23:42, Ben Atkin <ben@...> wrote:
>
> > **
> >
> >
> > Don't tell me what to do.
> >
> >
> > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > >
> > > Don't complain that JSON isn't what you want it to be. There are plenty
> > of
> > > alternative formats, use one of them, instead.
> > >
> > > On 10 July 2012 23:39, Ben Atkin <ben@> wrote:
> > >
> > > > **
> >
> > > >
> > > >
> > > > Which format should I use, then? XML?
> > > >
> > > > http://www.coderanch.com/t/128908/XML/Preserve-comments-XSL
> > > >
> > > > But I like JSON! Also these configs are going to get turned into a JSON
> > > > structure at some point, whether it's parsing eon, or converting eon to
> > > > JSON before parsing it.
> > > >
> > > >
> > > > Ben
> > > >
> > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > >
> > > > > You don't want JSON, then. JSON isn't designed to update an existing
> > > > file,
> > > > > it deserialises and serialises.
> > > > >
> > > > > On 10 July 2012 23:18, Ben Atkin <ben@> wrote:
> > > > >
> > > > > > **
> > > >
> > > > > >
> > > > > >
> > > > > > Thanks for pointing that out.
> > > > > >
> > > > > > That reminds me - another thing I want is to be able to
> > automatically
> > > > > > change something in an eon file without stripping out comments or
> > > > > > whitespace or changing the order of things. This will require a
> > parser
> > > > of
> > > > > > sorts and not just a minifying step.
> > > > > >
> > > > > > Ben
> > > > > >
> > > > > >
> > > > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > > > >
> > > > > > > JSMin isn't a full-blown filter, it relies on valid JS/JSON being
> > > > passed
> > > > > > > in. pass in "b + ++a" and you'll get "b+++a" out.
> > > > > > >
> > > > > > > On 10 July 2012 23:12, Ben Atkin <ben@> wrote:
> > > > > > >
> > > > > > > > **
> > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I agree filtering makes sense, but why run it through a
> > full-blown
> > > > > > filter
> > > > > > > > when all I want is to support comments? I think this is a nice
> > > > > > efficient
> > > > > > > > and simple tool for just removing comments:
> > > > > > > > https://github.com/kitcambridge/json-compressor
> > > > > > > >
> > > > > > > > I'm thinking of using that as the main way and only using my
> > custom
> > > > > > jison
> > > > > > > > parser when I want to give detailed error messages.
> > > > > > > >
> > > > > > > > Also a main goal I have is to get it to work in multiple
> > > > programming
> > > > > > > > languages. Most of my test suite is JSON - it just has a tiny
> > > > runner
> > > > > > that
> > > > > > > > iterates through the test data, so that makes it easy to port.
> > > > Having a
> > > > > > > > native version could make it easier for users of the other
> > > > languages.
> > > > > > > >
> > > > > > > > Ben
> > > > > > > >
> > > > > > > > --- In json@yahoogroups.com, "douglascrockford" <douglas@>
> > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > > > > > > >
> > > > > > > > > > The standard is respected in most places. Try adding
> > comments
> > > > and
> > > > > > then
> > > > > > > > using a common JSON parser (like the one in Firefox or Chrome)
> > and
> > > > > > you'll
> > > > > > > > see an error. Because of that, it's foolish to output JSON that
> > > > doesn't
> > > > > > > > conform to the spec.
> > > > > > > > > >
> > > > > > > > > > I'm not especially interested in the three changes in the
> > > > original
> > > > > > > > thread. What I do find interesting is comment support. JSON is
> > so
> > > > nice
> > > > > > and
> > > > > > > > simple that it's often being used for configuration and not
> > just
> > > > > > > > serialization. In many cases, comments are more useful than
> > > > > > problematic in
> > > > > > > > configuration files. For this reason I'm working on making a
> > > > standard
> > > > > > > > format that is simply JSON+comments, and I'm calling it Eon
> > > > (EcmaScript
> > > > > > > > Object Notation). I think if you're going to try to come up
> > with
> > > > your
> > > > > > own
> > > > > > > > JSON-like format, you should come up with a file extension and
> > > > > > content-type
> > > > > > > > that doesn't contain "json". Some HTTP client libraries will
> > try to
> > > > > > parse
> > > > > > > > everything that has the substring "json" in its content type,
> > and
> > > > it's
> > > > > > best
> > > > > > > > not to break those, even though they should arguably be
> > checking
> > > > for
> > > > > > word
> > > > > > > > boundaries.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > You don't need a new standard. Just pipe JSMin in front of
> > your
> > > > JSON
> > > > > > > > parser.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Andrew Faulds (AJF)
> > > > > > > http://ajf.me/
> > > > > > >
> > > > > > >
> > > > > > > [Non-text portions of this message have been removed]
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andrew Faulds (AJF)
> > > > > http://ajf.me/
> > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Andrew Faulds (AJF)
> > > http://ajf.me/
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
>
> --
> Andrew Faulds (AJF)
> http://ajf.me/
>
>
> [Non-text portions of this message have been removed]
>

Ah, I see. Well, I'd suggest changing the name to something more geared
towards configuration... ECL, perhaps?

On 11 July 2012 00:12, Ben Atkin <ben@...> wrote:

> **
>
>
> Thanks; I realize that, and also that since I'm the one making a file
> format I should be more accepting of criticism.
>
> But I don't mean to be whining. I see people using JSON for complex
> human-edited configuration files, and it's a testament to how much nicer it
> is than XML and more approachable it is than YAML. And for a lot of
> configuration formats, comments aren't all that useful.
>
> But some people really want traditional comments, and they are calling
> their files with comments json. And this could break things. I'd like to
> provide an alternative to call it something else so they'll know that it
> needs to be run through a minifier before handing it off to a json parser.
>
> Ben
>
>
> --- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
> >
> > I'm not telling you what to do, I'm just saying that whining that a fixed
> > standard, which is designed for something different to what you want,
> does
> > not do what you want, is rather pointless.
> >
> > On 10 July 2012 23:42, Ben Atkin <ben@...> wrote:
> >
> > > **
>
> > >
> > >
> > > Don't tell me what to do.
> > >
> > >
> > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > >
> > > > Don't complain that JSON isn't what you want it to be. There are
> plenty
> > > of
> > > > alternative formats, use one of them, instead.
> > > >
> > > > On 10 July 2012 23:39, Ben Atkin <ben@> wrote:
> > > >
> > > > > **
> > >
> > > > >
> > > > >
> > > > > Which format should I use, then? XML?
> > > > >
> > > > > http://www.coderanch.com/t/128908/XML/Preserve-comments-XSL
> > > > >
> > > > > But I like JSON! Also these configs are going to get turned into a
> JSON
> > > > > structure at some point, whether it's parsing eon, or converting
> eon to
> > > > > JSON before parsing it.
> > > > >
> > > > >
> > > > > Ben
> > > > >
> > > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > > >
> > > > > > You don't want JSON, then. JSON isn't designed to update an
> existing
> > > > > file,
> > > > > > it deserialises and serialises.
> > > > > >
> > > > > > On 10 July 2012 23:18, Ben Atkin <ben@> wrote:
> > > > > >
> > > > > > > **
> > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks for pointing that out.
> > > > > > >
> > > > > > > That reminds me - another thing I want is to be able to
> > > automatically
> > > > > > > change something in an eon file without stripping out comments
> or
> > > > > > > whitespace or changing the order of things. This will require a
> > > parser
> > > > > of
> > > > > > > sorts and not just a minifying step.
> > > > > > >
> > > > > > > Ben
> > > > > > >
> > > > > > >
> > > > > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > > > > >
> > > > > > > > JSMin isn't a full-blown filter, it relies on valid JS/JSON
> being
> > > > > passed
> > > > > > > > in. pass in "b + ++a" and you'll get "b+++a" out.
> > > > > > > >
> > > > > > > > On 10 July 2012 23:12, Ben Atkin <ben@> wrote:
> > > > > > > >
> > > > > > > > > **
> > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I agree filtering makes sense, but why run it through a
> > > full-blown
> > > > > > > filter
> > > > > > > > > when all I want is to support comments? I think this is a
> nice
> > > > > > > efficient
> > > > > > > > > and simple tool for just removing comments:
> > > > > > > > > https://github.com/kitcambridge/json-compressor
> > > > > > > > >
> > > > > > > > > I'm thinking of using that as the main way and only using
> my
> > > custom
> > > > > > > jison
> > > > > > > > > parser when I want to give detailed error messages.
> > > > > > > > >
> > > > > > > > > Also a main goal I have is to get it to work in multiple
> > > > > programming
> > > > > > > > > languages. Most of my test suite is JSON - it just has a
> tiny
> > > > > runner
> > > > > > > that
> > > > > > > > > iterates through the test data, so that makes it easy to
> port.
> > > > > Having a
> > > > > > > > > native version could make it easier for users of the other
> > > > > languages.
> > > > > > > > >
> > > > > > > > > Ben
> > > > > > > > >
> > > > > > > > > --- In json@yahoogroups.com, "douglascrockford" <douglas@>
> > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > > > > > > > >
> > > > > > > > > > > The standard is respected in most places. Try adding
> > > comments
> > > > > and
> > > > > > > then
> > > > > > > > > using a common JSON parser (like the one in Firefox or
> Chrome)
> > > and
> > > > > > > you'll
> > > > > > > > > see an error. Because of that, it's foolish to output JSON
> that
> > > > > doesn't
> > > > > > > > > conform to the spec.
> > > > > > > > > > >
> > > > > > > > > > > I'm not especially interested in the three changes in
> the
> > > > > original
> > > > > > > > > thread. What I do find interesting is comment support.
> JSON is
> > > so
> > > > > nice
> > > > > > > and
> > > > > > > > > simple that it's often being used for configuration and not
> > > just
> > > > > > > > > serialization. In many cases, comments are more useful than
> > > > > > > problematic in
> > > > > > > > > configuration files. For this reason I'm working on making
> a
> > > > > standard
> > > > > > > > > format that is simply JSON+comments, and I'm calling it Eon
> > > > > (EcmaScript
> > > > > > > > > Object Notation). I think if you're going to try to come up
> > > with
> > > > > your
> > > > > > > own
> > > > > > > > > JSON-like format, you should come up with a file extension
> and
> > > > > > > content-type
> > > > > > > > > that doesn't contain "json". Some HTTP client libraries
> will
> > > try to
> > > > > > > parse
> > > > > > > > > everything that has the substring "json" in its content
> type,
> > > and
> > > > > it's
> > > > > > > best
> > > > > > > > > not to break those, even though they should arguably be
> > > checking
> > > > > for
> > > > > > > word
> > > > > > > > > boundaries.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > You don't need a new standard. Just pipe JSMin in front
> of
> > > your
> > > > > JSON
> > > > > > > > > parser.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Andrew Faulds (AJF)
> > > > > > > > http://ajf.me/
> > > > > > > >
> > > > > > > >
> > > > > > > > [Non-text portions of this message have been removed]
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Andrew Faulds (AJF)
> > > > > > http://ajf.me/
> > > > > >
> > > > > >
> > > > > > [Non-text portions of this message have been removed]
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Andrew Faulds (AJF)
> > > > http://ajf.me/
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Andrew Faulds (AJF)
> > http://ajf.me/
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

I wanted to pick something that didn't sound too much like JSON or too little
like JSON. Too much like JSON and you get breakage. Too little like JSON and
people forget that while the format is different, the data model is exactly the
same. I think eon is a nice compromise.

Ben

--- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
>
> Ah, I see. Well, I'd suggest changing the name to something more geared
> towards configuration... ECL, perhaps?
>
> On 11 July 2012 00:12, Ben Atkin <ben@...> wrote:
>
> > **
> >
> >
> > Thanks; I realize that, and also that since I'm the one making a file
> > format I should be more accepting of criticism.
> >
> > But I don't mean to be whining. I see people using JSON for complex
> > human-edited configuration files, and it's a testament to how much nicer it
> > is than XML and more approachable it is than YAML. And for a lot of
> > configuration formats, comments aren't all that useful.
> >
> > But some people really want traditional comments, and they are calling
> > their files with comments json. And this could break things. I'd like to
> > provide an alternative to call it something else so they'll know that it
> > needs to be run through a minifier before handing it off to a json parser.
> >
> > Ben
> >
> >
> > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > >
> > > I'm not telling you what to do, I'm just saying that whining that a fixed
> > > standard, which is designed for something different to what you want,
> > does
> > > not do what you want, is rather pointless.
> > >
> > > On 10 July 2012 23:42, Ben Atkin <ben@> wrote:
> > >
> > > > **
> >
> > > >
> > > >
> > > > Don't tell me what to do.
> > > >
> > > >
> > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > >
> > > > > Don't complain that JSON isn't what you want it to be. There are
> > plenty
> > > > of
> > > > > alternative formats, use one of them, instead.
> > > > >
> > > > > On 10 July 2012 23:39, Ben Atkin <ben@> wrote:
> > > > >
> > > > > > **
> > > >
> > > > > >
> > > > > >
> > > > > > Which format should I use, then? XML?
> > > > > >
> > > > > > http://www.coderanch.com/t/128908/XML/Preserve-comments-XSL
> > > > > >
> > > > > > But I like JSON! Also these configs are going to get turned into a
> > JSON
> > > > > > structure at some point, whether it's parsing eon, or converting
> > eon to
> > > > > > JSON before parsing it.
> > > > > >
> > > > > >
> > > > > > Ben
> > > > > >
> > > > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > > > >
> > > > > > > You don't want JSON, then. JSON isn't designed to update an
> > existing
> > > > > > file,
> > > > > > > it deserialises and serialises.
> > > > > > >
> > > > > > > On 10 July 2012 23:18, Ben Atkin <ben@> wrote:
> > > > > > >
> > > > > > > > **
> > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks for pointing that out.
> > > > > > > >
> > > > > > > > That reminds me - another thing I want is to be able to
> > > > automatically
> > > > > > > > change something in an eon file without stripping out comments
> > or
> > > > > > > > whitespace or changing the order of things. This will require a
> > > > parser
> > > > > > of
> > > > > > > > sorts and not just a minifying step.
> > > > > > > >
> > > > > > > > Ben
> > > > > > > >
> > > > > > > >
> > > > > > > > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@> wrote:
> > > > > > > > >
> > > > > > > > > JSMin isn't a full-blown filter, it relies on valid JS/JSON
> > being
> > > > > > passed
> > > > > > > > > in. pass in "b + ++a" and you'll get "b+++a" out.
> > > > > > > > >
> > > > > > > > > On 10 July 2012 23:12, Ben Atkin <ben@> wrote:
> > > > > > > > >
> > > > > > > > > > **
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I agree filtering makes sense, but why run it through a
> > > > full-blown
> > > > > > > > filter
> > > > > > > > > > when all I want is to support comments? I think this is a
> > nice
> > > > > > > > efficient
> > > > > > > > > > and simple tool for just removing comments:
> > > > > > > > > > https://github.com/kitcambridge/json-compressor
> > > > > > > > > >
> > > > > > > > > > I'm thinking of using that as the main way and only using
> > my
> > > > custom
> > > > > > > > jison
> > > > > > > > > > parser when I want to give detailed error messages.
> > > > > > > > > >
> > > > > > > > > > Also a main goal I have is to get it to work in multiple
> > > > > > programming
> > > > > > > > > > languages. Most of my test suite is JSON - it just has a
> > tiny
> > > > > > runner
> > > > > > > > that
> > > > > > > > > > iterates through the test data, so that makes it easy to
> > port.
> > > > > > Having a
> > > > > > > > > > native version could make it easier for users of the other
> > > > > > languages.
> > > > > > > > > >
> > > > > > > > > > Ben
> > > > > > > > > >
> > > > > > > > > > --- In json@yahoogroups.com, "douglascrockford" <douglas@>
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > The standard is respected in most places. Try adding
> > > > comments
> > > > > > and
> > > > > > > > then
> > > > > > > > > > using a common JSON parser (like the one in Firefox or
> > Chrome)
> > > > and
> > > > > > > > you'll
> > > > > > > > > > see an error. Because of that, it's foolish to output JSON
> > that
> > > > > > doesn't
> > > > > > > > > > conform to the spec.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not especially interested in the three changes in
> > the
> > > > > > original
> > > > > > > > > > thread. What I do find interesting is comment support.
> > JSON is
> > > > so
> > > > > > nice
> > > > > > > > and
> > > > > > > > > > simple that it's often being used for configuration and not
> > > > just
> > > > > > > > > > serialization. In many cases, comments are more useful than
> > > > > > > > problematic in
> > > > > > > > > > configuration files. For this reason I'm working on making
> > a
> > > > > > standard
> > > > > > > > > > format that is simply JSON+comments, and I'm calling it Eon
> > > > > > (EcmaScript
> > > > > > > > > > Object Notation). I think if you're going to try to come up
> > > > with
> > > > > > your
> > > > > > > > own
> > > > > > > > > > JSON-like format, you should come up with a file extension
> > and
> > > > > > > > content-type
> > > > > > > > > > that doesn't contain "json". Some HTTP client libraries
> > will
> > > > try to
> > > > > > > > parse
> > > > > > > > > > everything that has the substring "json" in its content
> > type,
> > > > and
> > > > > > it's
> > > > > > > > best
> > > > > > > > > > not to break those, even though they should arguably be
> > > > checking
> > > > > > for
> > > > > > > > word
> > > > > > > > > > boundaries.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > You don't need a new standard. Just pipe JSMin in front
> > of
> > > > your
> > > > > > JSON
> > > > > > > > > > parser.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Andrew Faulds (AJF)
> > > > > > > > > http://ajf.me/
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [Non-text portions of this message have been removed]
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Andrew Faulds (AJF)
> > > > > > > http://ajf.me/
> > > > > > >
> > > > > > >
> > > > > > > [Non-text portions of this message have been removed]
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andrew Faulds (AJF)
> > > > > http://ajf.me/
> > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Andrew Faulds (AJF)
> > > http://ajf.me/
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
>
> --
> Andrew Faulds (AJF)
> http://ajf.me/
>
>
> [Non-text portions of this message have been removed]
>

On Tue, Jul 10, 2012 at 4:35 PM, Ben Atkin <ben@...> wrote:
> I wanted to pick something that didn't sound too much like JSON or too little
like JSON. Too much like JSON and you get breakage. Too little like JSON and
people forget that while the format is different, the data model is exactly the
same. I think eon is a nice compromise.

If it is "JSON with comments", could call it json-c or jsonc, if
"json-with-comments" is too long?
Similar to how json-p (json with padding) is called; it's not JSON either.

Comments are perhaps the single one thing I really wish JSON had,
omission of which was IMO a grave mistake for any textual format.

-+ Tatu +-

JSON had them, Crockford removed them because people used them for parsing
directives which was problematic as it fragmented the standard and stopped
there being just one "JSON".

On 11 July 2012 00:56, Tatu Saloranta <tsaloranta@...> wrote:

> **
>
>
> On Tue, Jul 10, 2012 at 4:35 PM, Ben Atkin <ben@...> wrote:
> > I wanted to pick something that didn't sound too much like JSON or too
> little like JSON. Too much like JSON and you get breakage. Too little like
> JSON and people forget that while the format is different, the data model
> is exactly the same. I think eon is a nice compromise.
>
> If it is "JSON with comments", could call it json-c or jsonc, if
> "json-with-comments" is too long?
> Similar to how json-p (json with padding) is called; it's not JSON either.
>
> Comments are perhaps the single one thing I really wish JSON had,
> omission of which was IMO a grave mistake for any textual format.
>
> -+ Tatu +-
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

--- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
> Comments are perhaps the single one thing I really wish JSON had,
> omission of which was IMO a grave mistake for any textual format.


I'll say this one more time: If you want comments, then pipe JSMin in front of
your JSON parser. You don't need a new standard.

WOW! My mailbox doubled in volume in 4 hrs from this normally quiet mail list.

I think this concept has stirred a hornets nest.

I'll read this idea near the end of the debate.


Sent from Yahoo! Mail on Android



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

On Tue, Jul 10, 2012 at 5:38 PM, douglascrockford <douglas@...> wrote:
> --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>> Comments are perhaps the single one thing I really wish JSON had,
>> omission of which was IMO a grave mistake for any textual format.
>
>
> I'll say this one more time: If you want comments, then pipe JSMin in front of
your JSON parser. You don't need a new standard.

What a great idea -- instead of having comments in where they belong,
format spec, add a non-standard pre-processor. I really miss C coding.

I am not advocate of a new format, but I am highly critical of this
one big flaw in JSON spec.

But that's that, it's not in the spec, and not much can be done about it.

-+ Tatu +-

Given that YAML is a superset of JSON, you could standardize on YAML but
encourage folks to make it look like JSON.

-EJ

On Jul 10, 2012, at 9:01 PM, Tatu Saloranta wrote:

> On Tue, Jul 10, 2012 at 5:38 PM, douglascrockford <douglas@...>
wrote:
>> --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>>> Comments are perhaps the single one thing I really wish JSON had,
>>> omission of which was IMO a grave mistake for any textual format.
>>
>>
>> I'll say this one more time: If you want comments, then pipe JSMin in front
of your JSON parser. You don't need a new standard.
>
> What a great idea -- instead of having comments in where they belong,
> format spec, add a non-standard pre-processor. I really miss C coding.
>
> I am not advocate of a new format, but I am highly critical of this
> one big flaw in JSON spec.
>
> But that's that, it's not in the spec, and not much can be done about it.
>
> -+ Tatu +-
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

As mentioned *countless* times, comments were removed from the JSON spec.
On Jul 11, 2012 5:01 AM, "Tatu Saloranta" <tsaloranta@...> wrote:

> **
>
>
> On Tue, Jul 10, 2012 at 5:38 PM, douglascrockford <douglas@...>
> wrote:
> > --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
> >> Comments are perhaps the single one thing I really wish JSON had,
> >> omission of which was IMO a grave mistake for any textual format.
> >
> >
> > I'll say this one more time: If you want comments, then pipe JSMin in
> front of your JSON parser. You don't need a new standard.
>
> What a great idea -- instead of having comments in where they belong,
> format spec, add a non-standard pre-processor. I really miss C coding.
>
> I am not advocate of a new format, but I am highly critical of this
> one big flaw in JSON spec.
>
> But that's that, it's not in the spec, and not much can be done about it.
>
> -+ Tatu +-
>
>


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

That is an interesting idea. It sounds more like a
configuration-file-editor than a parser. Parsers normally ignore
whitespaces and comments as being no part of the data, but you want to
leave all this meta-data intact. Sounds very useful for config editing.

If you consider comments as part of the data itself instead of some
non-necessary meta-data, it may be a better idea to store these comments in
the data itself, in some reserved field like "$comment" or "_comment" as
Andrew suggested.

Jos


On Wed, Jul 11, 2012 at 12:18 AM, Ben Atkin <ben@...> wrote:

> **
>
>
> Thanks for pointing that out.
>
> That reminds me - another thing I want is to be able to automatically
> change something in an eon file without stripping out comments or
> whitespace or changing the order of things. This will require a parser of
> sorts and not just a minifying step.
>
> Ben
>
>
> --- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
> >
> > JSMin isn't a full-blown filter, it relies on valid JS/JSON being passed
> > in. pass in "b + ++a" and you'll get "b+++a" out.
> >
> > On 10 July 2012 23:12, Ben Atkin <ben@...> wrote:
> >
> > > **
> > >
> > >
> > > I agree filtering makes sense, but why run it through a full-blown
> filter
> > > when all I want is to support comments? I think this is a nice
> efficient
> > > and simple tool for just removing comments:
> > > https://github.com/kitcambridge/json-compressor
> > >
> > > I'm thinking of using that as the main way and only using my custom
> jison
> > > parser when I want to give detailed error messages.
> > >
> > > Also a main goal I have is to get it to work in multiple programming
> > > languages. Most of my test suite is JSON - it just has a tiny runner
> that
> > > iterates through the test data, so that makes it easy to port. Having a
> > > native version could make it easier for users of the other languages.
> > >
> > > Ben
> > >
> > > --- In json@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> > >
> > > >
> > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > >
> > > > > The standard is respected in most places. Try adding comments and
> then
> > > using a common JSON parser (like the one in Firefox or Chrome) and
> you'll
> > > see an error. Because of that, it's foolish to output JSON that doesn't
> > > conform to the spec.
> > > > >
> > > > > I'm not especially interested in the three changes in the original
> > > thread. What I do find interesting is comment support. JSON is so nice
> and
> > > simple that it's often being used for configuration and not just
> > > serialization. In many cases, comments are more useful than
> problematic in
> > > configuration files. For this reason I'm working on making a standard
> > > format that is simply JSON+comments, and I'm calling it Eon (EcmaScript
> > > Object Notation). I think if you're going to try to come up with your
> own
> > > JSON-like format, you should come up with a file extension and
> content-type
> > > that doesn't contain "json". Some HTTP client libraries will try to
> parse
> > > everything that has the substring "json" in its content type, and it's
> best
> > > not to break those, even though they should arguably be checking for
> word
> > > boundaries.
> > > >
> > > >
> > > > You don't need a new standard. Just pipe JSMin in front of your JSON
> > > parser.
> > > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Andrew Faulds (AJF)
> > http://ajf.me/
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>


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

I think we are mixing up two things:

- *Using JSON for data serialization/deserialization*. That is what JSON is
meant for. Whitespaces and comments are irrelevant in this case. If you
want to add comments, you should put them in the data itself in a regular
field like "$comment" or "_comment".
-* Using JSON for storing configuration files*. This is *not* what JSON is
meant for. For configuration files, comments and whitespaces are important
and very helpful. I personally don't think JSON is that handy for storing
configuration: you have to enter (nested) accolades and comma's all the
time, which is not that human friendly. It is really easy to screw up the *
whole* configuration file by forgetting an accolade, double-quote, or comma
somewhere... Better use an existing standard like YAML or something else.
This is much better readable and editable for humans. As these standards
already exist and are widely used/supported, I don't really see the added
value of EON.

Jos

On Wed, Jul 11, 2012 at 6:01 AM, Tatu Saloranta <tsaloranta@...>wrote:

> **
>
>
> On Tue, Jul 10, 2012 at 5:38 PM, douglascrockford <douglas@...>
> wrote:
> > --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
> >> Comments are perhaps the single one thing I really wish JSON had,
> >> omission of which was IMO a grave mistake for any textual format.
> >
> >
> > I'll say this one more time: If you want comments, then pipe JSMin in
> front of your JSON parser. You don't need a new standard.
>
> What a great idea -- instead of having comments in where they belong,
> format spec, add a non-standard pre-processor. I really miss C coding.
>
> I am not advocate of a new format, but I am highly critical of this
> one big flaw in JSON spec.
>
> But that's that, it's not in the spec, and not much can be done about it.
>
> -+ Tatu +-
>
>
>


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

Yeah, that's my idea. I think, actually, you could do this with existing
JSON parsers by asking them to preserve key ordering.
On Jul 11, 2012 12:11 PM, "Jos de Jong" <wjosdejong@...> wrote:

> That is an interesting idea. It sounds more like a
> configuration-file-editor than a parser. Parsers normally ignore
> whitespaces and comments as being no part of the data, but you want to
> leave all this meta-data intact. Sounds very useful for config editing.
>
> If you consider comments as part of the data itself instead of some
> non-necessary meta-data, it may be a better idea to store these comments in
> the data itself, in some reserved field like "$comment" or "_comment" as
> Andrew suggested.
>
> Jos
>
>
> On Wed, Jul 11, 2012 at 12:18 AM, Ben Atkin <ben@...> wrote:
>
> > **
> >
> >
> > Thanks for pointing that out.
> >
> > That reminds me - another thing I want is to be able to automatically
> > change something in an eon file without stripping out comments or
> > whitespace or changing the order of things. This will require a parser of
> > sorts and not just a minifying step.
> >
> > Ben
> >
> >
> > --- In json@yahoogroups.com, Andrew Faulds <ajfweb@...> wrote:
> > >
> > > JSMin isn't a full-blown filter, it relies on valid JS/JSON being
> passed
> > > in. pass in "b + ++a" and you'll get "b+++a" out.
> > >
> > > On 10 July 2012 23:12, Ben Atkin <ben@...> wrote:
> > >
> > > > **
> > > >
> > > >
> > > > I agree filtering makes sense, but why run it through a full-blown
> > filter
> > > > when all I want is to support comments? I think this is a nice
> > efficient
> > > > and simple tool for just removing comments:
> > > > https://github.com/kitcambridge/json-compressor
> > > >
> > > > I'm thinking of using that as the main way and only using my custom
> > jison
> > > > parser when I want to give detailed error messages.
> > > >
> > > > Also a main goal I have is to get it to work in multiple programming
> > > > languages. Most of my test suite is JSON - it just has a tiny runner
> > that
> > > > iterates through the test data, so that makes it easy to port.
> Having a
> > > > native version could make it easier for users of the other languages.
> > > >
> > > > Ben
> > > >
> > > > --- In json@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> > > >
> > > > >
> > > > > --- In json@yahoogroups.com, "Ben Atkin" <ben@> wrote:
> > > > > >
> > > > > > The standard is respected in most places. Try adding comments and
> > then
> > > > using a common JSON parser (like the one in Firefox or Chrome) and
> > you'll
> > > > see an error. Because of that, it's foolish to output JSON that
> doesn't
> > > > conform to the spec.
> > > > > >
> > > > > > I'm not especially interested in the three changes in the
> original
> > > > thread. What I do find interesting is comment support. JSON is so
> nice
> > and
> > > > simple that it's often being used for configuration and not just
> > > > serialization. In many cases, comments are more useful than
> > problematic in
> > > > configuration files. For this reason I'm working on making a standard
> > > > format that is simply JSON+comments, and I'm calling it Eon
> (EcmaScript
> > > > Object Notation). I think if you're going to try to come up with your
> > own
> > > > JSON-like format, you should come up with a file extension and
> > content-type
> > > > that doesn't contain "json". Some HTTP client libraries will try to
> > parse
> > > > everything that has the substring "json" in its content type, and
> it's
> > best
> > > > not to break those, even though they should arguably be checking for
> > word
> > > > boundaries.
> > > > >
> > > > >
> > > > > You don't need a new standard. Just pipe JSMin in front of your
> JSON
> > > > parser.
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Andrew Faulds (AJF)
> > > http://ajf.me/
> > >
> > >
> > > [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]

For this to be practical, there would have to be a version of JSMin for all
languages, and maybe a nice shebang at the top (or at least a note to the meat
computers):

#!/bin/JSMin

However, my opinion is that since JSON is supposed to be JScript, leaving out
comments was non sequetor, Douglas :-(. And since JSON is so popular, changing
the spec would be disseminated quite rapidly.

Does doing a simple, bad practice 'eval(JSON-containing-comments)' work?

  Dennis Gearon


Never, ever approach a computer saying or even thinking "I will just do this
quickly."




________________________________
From: douglascrockford <douglas@...>
To: json@yahoogroups.com
Sent: Tue, July 10, 2012 1:53:41 PM
Subject: [json] Re: JSON Propositions


--- In json@yahoogroups.com, "Ben Atkin" <ben@...> wrote:
>
> The standard is respected in most places. Try adding comments and then using a
>common JSON parser (like the one in Firefox or Chrome) and you'll see an error.
>Because of that, it's foolish to output JSON that doesn't conform to the spec.
>
> I'm not especially interested in the three changes in the original thread.
What
>I do find interesting is comment support. JSON is so nice and simple that it's
>often being used for configuration and not just serialization. In many cases,
>comments are more useful than problematic in configuration files. For this
>reason I'm working on making a standard format that is simply JSON+comments,
and
>I'm calling it Eon (EcmaScript Object Notation). I think if you're going to try
>to come up with your own JSON-like format, you should come up with a file
>extension and content-type that doesn't contain "json". Some HTTP client
>libraries will try to parse everything that has the substring "json" in its
>content type, and it's best not to break those, even though they should
arguably
>be checking for word boundaries.

You don't need a new standard. Just pipe JSMin in front of your JSON parser.




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

How many times do these things have to be made clear?

- JSON is a subset of ECMAScript 3, not just JavaScript
- JSON used to have comments, but they were removed since people used them
for parsing directives
- JSON is not a configuration file format, and is for data serialisation
- JSON is never, ever, ever going to change, no matter how much you want it
to

Thanks.

On 11 July 2012 16:54, Dennis Gearon <gearond@...> wrote:

> **
>
>
> For this to be practical, there would have to be a version of JSMin for
> all
> languages, and maybe a nice shebang at the top (or at least a note to the
> meat
> computers):
>
> #!/bin/JSMin
>
> However, my opinion is that since JSON is supposed to be JScript, leaving
> out
> comments was non sequetor, Douglas :-(. And since JSON is so popular,
> changing
> the spec would be disseminated quite rapidly.
>
> Does doing a simple, bad practice 'eval(JSON-containing-comments)' work?
>
> Dennis Gearon
>
> Never, ever approach a computer saying or even thinking "I will just do
> this
> quickly."
>
> ________________________________
> From: douglascrockford <douglas@...>
> To: json@yahoogroups.com
> Sent: Tue, July 10, 2012 1:53:41 PM
> Subject: [json] Re: JSON Propositions
>
>
> --- In json@yahoogroups.com, "Ben Atkin" <ben@...> wrote:
> >
> > The standard is respected in most places. Try adding comments and then
> using a
> >common JSON parser (like the one in Firefox or Chrome) and you'll see an
> error.
> >Because of that, it's foolish to output JSON that doesn't conform to the
> spec.
> >
> > I'm not especially interested in the three changes in the original
> thread. What
> >I do find interesting is comment support. JSON is so nice and simple that
> it's
> >often being used for configuration and not just serialization. In many
> cases,
> >comments are more useful than problematic in configuration files. For
> this
> >reason I'm working on making a standard format that is simply
> JSON+comments, and
> >I'm calling it Eon (EcmaScript Object Notation). I think if you're going
> to try
> >to come up with your own JSON-like format, you should come up with a file
> >extension and content-type that doesn't contain "json". Some HTTP client
> >libraries will try to parse everything that has the substring "json" in
> its
> >content type, and it's best not to break those, even though they should
> arguably
> >be checking for word boundaries.
>
> You don't need a new standard. Just pipe JSMin in front of your JSON
> parser.
>
> [Non-text portions of this message have been removed]
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

I'm trying to implement a JSON call to simulate AJAX on a certain page where an
AJAX panel isn't a viable option.


I want call my .aspx page when a State is selected from a drop down and populate
the Counties drop down.


in my State dropdown, I have this call:

onchange="jsonDropDownLoader('COUNTIES', this, 'Content2_DDLCounties')"


That call is on the page and the code is here:

function jsonDropDownLoader(sType, oParent, oChild) {
    var lstrChild = document.getElementById(oChild);
    var lstrFilter = ""

    if (oParent.value > "") {
        lstrFilter = oParent.value
    }

    lstrChild.options.length = 0;
    if (oParent.value > "") {
        var JSONobject = {};
        var http_request = new XMLHttpRequest();
        url = "/AltairWeb.NET/RS/jsonDropDownLoader.aspx?TYPE=" + sType +
"&FILTER=" + lstrFilter
        http_request.open("GET", url, false);
        http_request.onreadystatechange = function () {
            var done = 4, ok = 200;
            if (http_request.readyState == done && http_request.status == ok) {
                JSONobject = JSON.parse(http_request.responseText);
            }
        };
        http_request.send(null);
        var JSONarray = eval('(' + http_request.responseText + ')').data
        for (var i = 0; i < JSONarray.length; ++i) {
            var optn = document.createElement("OPTION");
            optn.text = JSONarray[i].text;
            optn.value = JSONarray[i].value;
            lstrChild.options.add(optn);
        }
    }
}

It returns a string which I then use to populate the County drop down.


I'm getting data back, but it's not rendering on your QA server. Using the
developer tools with IE8, I can see that I have a error on this line:

JSONobject = JSON.parse(http_request.responseText);
it says that JSON is not declared.


It says I also have a syntax error on this line:

var JSONarray = eval('(' + http_request.responseText + ')').data

This works perfectly on my development box. However, my development box has
WinXP / IIS 5 on it, whereas, our QA server is a Win2008 server with IIS7.5.  We
have new development boxes coming, but until then, I'm stuck with the XP
machine.

Since it works locally, it seems like it must be a security issue with either
Windows or IIS on the QA server, possibly with the http_request call, but I
can't find anything via google that has helped me figure this out.

Any ideas?

Thanks in advance!
Tim

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

Hey Tim,

IE8 doesn't have built-in JSON support, since it doesn't support ES5. You
should include Douglas's json2.js (
https://github.com/douglascrockford/JSON-js) in your page - it will create
the JSON object for older browsers that lack it, but newer ones can use
their native support.

Hope I can help.

On 11 July 2012 19:07, Reaus@... <reaus@...> wrote:

> **
>
>
> I'm trying to implement a JSON call to simulate AJAX on a certain page
> where an AJAX panel isn't a viable option.
>
> I want call my .aspx page when a State is selected from a drop down and
> populate the Counties drop down.
>
> in my State dropdown, I have this call:
>
> onchange="jsonDropDownLoader('COUNTIES', this, 'Content2_DDLCounties')"
>
> That call is on the page and the code is here:
>
> function jsonDropDownLoader(sType, oParent, oChild) {
>     var lstrChild = document.getElementById(oChild);
>     var lstrFilter = ""
>
>     if (oParent.value > "") {
>         lstrFilter = oParent.value
>     }
>
>     lstrChild.options.length = 0;
>     if (oParent.value > "") {
>         var JSONobject = {};
>         var http_request = new XMLHttpRequest();
>         url = "/AltairWeb.NET/RS/jsonDropDownLoader.aspx?TYPE=" + sType +
> "&FILTER=" + lstrFilter
>         http_request.open("GET", url, false);
>         http_request.onreadystatechange = function () {
>             var done = 4, ok = 200;
>             if (http_request.readyState == done && http_request.status ==
> ok) {
>                 JSONobject = JSON.parse(http_request.responseText);
>             }
>         };
>         http_request.send(null);
>         var JSONarray = eval('(' + http_request.responseText + ')').data
>         for (var i = 0; i < JSONarray.length; ++i) {
>             var optn = document.createElement("OPTION");
>             optn.text = JSONarray[i].text;
>             optn.value = JSONarray[i].value;
>             lstrChild.options.add(optn);
>         }
>     }
> }
>
> It returns a string which I then use to populate the County drop down.
>
> I'm getting data back, but it's not rendering on your QA server. Using the
> developer tools with IE8, I can see that I have a error on this line:
>
> JSONobject = JSON.parse(http_request.responseText);
> it says that JSON is not declared.
>
> It says I also have a syntax error on this line:
>
> var JSONarray = eval('(' + http_request.responseText + ')').data
>
> This works perfectly on my development box. However, my development box
> has WinXP / IIS 5 on it, whereas, our QA server is a Win2008 server with
> IIS7.5.  We have new development boxes coming, but until then, I'm stuck
> with the XP machine.
>
> Since it works locally, it seems like it must be a security issue with
> either Windows or IIS on the QA server, possibly with the http_request
> call, but I can't find anything via google that has helped me figure this
> out.
>
> Any ideas?
>
> Thanks in advance!
> Tim
>
> [Non-text portions of this message have been removed]
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

Actually IE8 does, it is IE7 that doesn’t.  But make sure you have the
"ECMAScript, fifth edition" patch to be fully compliant

http://support.microsoft.com/kb/976662

Brian

From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of Andrew
Faulds
Sent: Wednesday, July 11, 2012 2:10 PM
To: json@yahoogroups.com
Subject: Re: [json] Looking for help with syntax error



Hey Tim,

IE8 doesn't have built-in JSON support, since it doesn't support ES5. You
should include Douglas's json2.js (
https://github.com/douglascrockford/JSON-js) in your page - it will create
the JSON object for older browsers that lack it, but newer ones can use
their native support.

Hope I can help.

On 11 July 2012 19:07, Reaus@...<mailto:Reaus%40yahoo.com>
<reaus@...<mailto:reaus%40yahoo.com>> wrote:

> **
>
>
> I'm trying to implement a JSON call to simulate AJAX on a certain page
> where an AJAX panel isn't a viable option.
>
> I want call my .aspx page when a State is selected from a drop down and
> populate the Counties drop down.
>
> in my State dropdown, I have this call:
>
> onchange="jsonDropDownLoader('COUNTIES', this, 'Content2_DDLCounties')"
>
> That call is on the page and the code is here:
>
> function jsonDropDownLoader(sType, oParent, oChild) {
> var lstrChild = document.getElementById(oChild);
> var lstrFilter = ""
>
> if (oParent.value > "") {
> lstrFilter = oParent.value
> }
>
> lstrChild.options.length = 0;
> if (oParent.value > "") {
> var JSONobject = {};
> var http_request = new XMLHttpRequest();
> url = "/AltairWeb.NET/RS/jsonDropDownLoader.aspx?TYPE=" + sType +
> "&FILTER=" + lstrFilter
> http_request.open("GET", url, false);
> http_request.onreadystatechange = function () {
> var done = 4, ok = 200;
> if (http_request.readyState == done && http_request.status ==
> ok) {
> JSONobject = JSON.parse(http_request.responseText);
> }
> };
> http_request.send(null);
> var JSONarray = eval('(' + http_request.responseText + ')').data
> for (var i = 0; i < JSONarray.length; ++i) {
> var optn = document.createElement("OPTION");
> optn.text = JSONarray[i].text;
> optn.value = JSONarray[i].value;
> lstrChild.options.add(optn);
> }
> }
> }
>
> It returns a string which I then use to populate the County drop down.
>
> I'm getting data back, but it's not rendering on your QA server. Using the
> developer tools with IE8, I can see that I have a error on this line:
>
> JSONobject = JSON.parse(http_request.responseText);
> it says that JSON is not declared.
>
> It says I also have a syntax error on this line:
>
> var JSONarray = eval('(' + http_request.responseText + ')').data
>
> This works perfectly on my development box. However, my development box
> has WinXP / IIS 5 on it, whereas, our QA server is a Win2008 server with
> IIS7.5. We have new development boxes coming, but until then, I'm stuck
> with the XP machine.
>
> Since it works locally, it seems like it must be a security issue with
> either Windows or IIS on the QA server, possibly with the http_request
> call, but I can't find anything via google that has helped me figure this
> out.
>
> Any ideas?
>
> Thanks in advance!
> Tim
>
> [Non-text portions of this message have been removed]
>
>
>

--
Andrew Faulds (AJF)
http://ajf.me/

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


________________________________
This communication contains information of International Flavors & Fragrances
(IFF) and/or its affiliates that may be confidential, proprietary, copyrighted
and/or legally privileged, and is intended only for the addressee. Any copying,
dissemination or other use of this information by anyone other than the intended
recipient is prohibited. If you have received this communication in error,
please contact the sender and delete it from your system.



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

To figure out what is going wrong, just do some debugging of your
application - nothing special JSON related...

- inspect the contents of http_request.responseText, to verify if this is
indeed valid JSON data. You can put a debug point (if your browser supports
that), or output the response via console.log(http_request.responseText).
- test if your browser supports JSON, just do some tests in your browsers
console, see if JSON.parse('{"J":5,"0":"N"}') works for example


On Wed, Jul 11, 2012 at 8:07 PM, Reaus@... <reaus@...> wrote:

> **
>
>
> I'm trying to implement a JSON call to simulate AJAX on a certain page
> where an AJAX panel isn't a viable option.
>
> I want call my .aspx page when a State is selected from a drop down and
> populate the Counties drop down.
>
> in my State dropdown, I have this call:
>
> onchange="jsonDropDownLoader('COUNTIES', this, 'Content2_DDLCounties')"
>
> That call is on the page and the code is here:
>
> function jsonDropDownLoader(sType, oParent, oChild) {
>     var lstrChild = document.getElementById(oChild);
>     var lstrFilter = ""
>
>     if (oParent.value > "") {
>         lstrFilter = oParent.value
>     }
>
>     lstrChild.options.length = 0;
>     if (oParent.value > "") {
>         var JSONobject = {};
>         var http_request = new XMLHttpRequest();
>         url = "/AltairWeb.NET/RS/jsonDropDownLoader.aspx?TYPE=" + sType +
> "&FILTER=" + lstrFilter
>         http_request.open("GET", url, false);
>         http_request.onreadystatechange = function () {
>             var done = 4, ok = 200;
>             if (http_request.readyState == done && http_request.status ==
> ok) {
>                 JSONobject = JSON.parse(http_request.responseText);
>             }
>         };
>         http_request.send(null);
>         var JSONarray = eval('(' + http_request.responseText + ')').data
>         for (var i = 0; i < JSONarray.length; ++i) {
>             var optn = document.createElement("OPTION");
>             optn.text = JSONarray[i].text;
>             optn.value = JSONarray[i].value;
>             lstrChild.options.add(optn);
>         }
>     }
> }
>
> It returns a string which I then use to populate the County drop down.
>
> I'm getting data back, but it's not rendering on your QA server. Using the
> developer tools with IE8, I can see that I have a error on this line:
>
> JSONobject = JSON.parse(http_request.responseText);
> it says that JSON is not declared.
>
> It says I also have a syntax error on this line:
>
> var JSONarray = eval('(' + http_request.responseText + ')').data
>
> This works perfectly on my development box. However, my development box
> has WinXP / IIS 5 on it, whereas, our QA server is a Win2008 server with
> IIS7.5.  We have new development boxes coming, but until then, I'm stuck
> with the XP machine.
>
> Since it works locally, it seems like it must be a security issue with
> either Windows or IIS on the QA server, possibly with the http_request
> call, but I can't find anything via google that has helped me figure this
> out.
>
> Any ideas?
>
> Thanks in advance!
> Tim
>
> [Non-text portions of this message have been removed]
>
>
>


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

I checked the QA servers and they both have the latest patches.

I double checked the date / version # on jscript.dll and I have the latest
version of that as well.


Tim


(hopefully, this isn't a double post. I tried the "reply" button from the group,
but my replies didn't seem to be making it to the group)



________________________________
  From: Andrew Faulds <ajfweb@...>
To: json@yahoogroups.com
Sent: Wednesday, July 11, 2012 1:09 PM
Subject: Re: [json] Looking for help with syntax error


 
Hey Tim,

IE8 doesn't have built-in JSON support, since it doesn't support ES5. You
should include Douglas's json2.js (
https://github.com/douglascrockford/JSON-js) in your page - it will create
the JSON object for older browsers that lack it, but newer ones can use
their native support.

Hope I can help.

On 11 July 2012 19:07, Reaus@... <reaus@...> wrote:

> **
>
>
> I'm trying to implement a JSON call to simulate AJAX on a certain page
> where an AJAX panel isn't a viable option.
>
> I want call my .aspx page when a State is selected from a drop down and
> populate the Counties drop down.
>
> in my State dropdown, I have this call:
>
> onchange="jsonDropDownLoader('COUNTIES', this, 'Content2_DDLCounties')"
>
> That call is on the page and the code is here:
>
> function jsonDropDownLoader(sType, oParent, oChild) {
>     var lstrChild = document.getElementById(oChild);
>     var lstrFilter = ""
>
>     if (oParent.value > "") {
>         lstrFilter = oParent.value
>     }
>
>     lstrChild.options.length = 0;
>     if (oParent.value > "") {
>         var JSONobject = {};
>         var http_request = new XMLHttpRequest();
>         url = "/AltairWeb.NET/RS/jsonDropDownLoader.aspx?TYPE=" + sType +
> "&FILTER=" + lstrFilter
>         http_request.open("GET", url, false);
>         http_request.onreadystatechange = function () {
>             var done = 4, ok = 200;
>             if (http_request.readyState == done && http_request.status ==
> ok) {
>                 JSONobject = JSON.parse(http_request.responseText);
>             }
>         };
>         http_request.send(null);
>         var JSONarray = eval('(' + http_request.responseText + ')').data
>         for (var i = 0; i < JSONarray.length; ++i) {
>             var optn = document.createElement("OPTION");
>             optn.text = JSONarray[i].text;
>             optn.value = JSONarray[i].value;
>             lstrChild.options.add(optn);
>         }
>     }
> }
>
> It returns a string which I then use to populate the County drop down.
>
> I'm getting data back, but it's not rendering on your QA server. Using the
> developer tools with IE8, I can see that I have a error on this line:
>
> JSONobject = JSON.parse(http_request.responseText);
> it says that JSON is not declared.
>
> It says I also have a syntax error on this line:
>
> var JSONarray = eval('(' + http_request.responseText + ')').data
>
> This works perfectly on my development box. However, my development box
> has WinXP / IIS 5 on it, whereas, our QA server is a Win2008 server with
> IIS7.5.  We have new development boxes coming, but until then, I'm stuck
> with the XP machine.
>
> Since it works locally, it seems like it must be a security issue with
> either Windows or IIS on the QA server, possibly with the http_request
> call, but I can't find anything via google that has helped me figure this
> out.
>
> Any ideas?
>
> Thanks in advance!
> Tim
>
> [Non-text portions of this message have been removed]
>
>
>

--
Andrew Faulds (AJF)
http://ajf.me/

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




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