- Jan 5, 2006
>>It is up to the coder to define 'best practices' not the format to
impose or restrict them.
Agreed. The problem lies in some of the inconsistencies surrounding
the goals, purpose and application of JSON and which I am interested
in seeing disambiguated. As it stands, right now, the contents of
the specification are, without a doubt, really good enough for a
machine encoder. There is little information in there to guide the
decoders. A human encoder is only at the mercy of the decoder's
flexibility and there's even more trouble if the implementation
swaps from underneath his or her feet. Why are humans such a big
issue? Well, it's right there as the second claim in the
specification: "It is easy for humans to read and write." The rules
about strings and unquotable member names is less of a concern for
humans because allowing a smaller subset means remembering fewer
rules. However, the resistance to mention comments whatsoever is
just incomprehensible and beyond me.
common denominator to be compatible with other languages.
Incidentally, what is a data format doing concerning itself with
lanugages and bindings? I can understand leveraging familiarity with
existing syntax across the C-family of languages, but that can only
be used with grain of salt in the design of the data format. The
lowest common denominator argument is only good enough while things
--- In email@example.com, "George" <georgenava@y...> wrote:
> I agree 100% with you.
> Anything the JS parser allows is considered valid:
> - Comments
> - Quoted/Unquoted keys
> - Numbered Keys
> - Single/Double Quotes
> - Scientific Notation
> - Unicode
> It is up to the coder to define 'best practices' not the format to
> impose or restrict them.
> common denominator to be compatible with other languages.
> If your target are web apps, HTML and JS, just go and use the whole
> set and more.
> Crockford knows I always opposed his stubbornness ;-)
> --- In firstname.lastname@example.org, Martin Cooper <mfncooper@g...> wrote:
> > On 1/3/06, Douglas Crockford <douglas@c...> wrote:
> > >
> > > JSON has a string notation which is similar to that used in
> > > family languages. Strings are bounded by double quote
> > > Escapement is provided by the backslash. The spec specifically
> > > the slash to be escaped so that JSON can be delivered in HTML
> > These statements have me really wondering about what JSON is
> supposed to be.
> > The reasoning behind removing comments was that it would "more
> closely align
> > JSON with YAML and Python". Now we have double quoted strings
> which is
> > "similar to that used in the C family language", and so that
it "can be
> > delivered in HTML documents".
> > And here was me blithely thinking JSON was supposed to be
> > respect, it's beginning to seem like JSON is supposed to be a
> > languages as possible. Perhaps it should be renamed "MON" for
> Minimal Object
> > Notation? ;-) The "JSON" moniker is seeming less and less
> > The single quote convention is not included in JSON because it
> > > needed.
> > included it. It's convenient because it frequently allows you to
> > backslashes / escapes in string literals.
> > All strings can be represented with the double quote notation.
> > > C itself does not have single quote strings. Many PHP
> > to... (... and add PHP programmers to my list of not-so-smart-
> if they
> > can't understand string quoting... ;)
> > JSON requires that keys be quoted because of an error in the
> > > ECMAScript spec that disallows the use of unquoted reserved
> > > keys. The list of reserved words is surprisingly long and
> > > remember. The best practice is to always quote keys.
> > That is a good reason to document a "best practice". It is in no
> > reason to ban people from using unquoted key names.
> > As an historical note, the very first JSON message contained as
> > > its keys the word "do". It was not quoted, and it caused a
> > Not a good start, huh? ;-)
> > --
> > Martin Cooper
> > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > [Non-text portions of this message have been removed]
- << Previous post in topic Next post in topic >>