185RE: [json] Re: Comments
- Jan 3 4:50 PM
> I think the real crux...As I said, I have a sneaking hunch that the real issue stems from tying
JSON to YAML. With the comments debate generating some traffic, I feel
less daring at this point to open up the disappearing of single-quoted
strings gone as well as unquoted member names (at least on the decoding
end). I am hoping Douglas will provide some insight so everyone can
build a better understanding of the decisions that lead to several
cutbacks in the specs. I think focusing the discussion too much on
comments is really just avoiding a more fundamental issue. Does anyone
agree or am I just rambling here?
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of
Sent: Tuesday, January 03, 2006 8:03 PM
Subject: Re: [json] Re: Comments
I think the real crux of this is simply, you cannot create a json
format string through encoding from existing data that would contain
comments (IIRC). It is only from people creating a json format string
It is a fairly weak argument that the standard should support
something that is not going to be used by the majority of people and
probably not in production, from an early version of the standard,
especially given that there are other ways get the same information
across using the current standard.
If you want to block out sections of json for ease of testing, then
comment out the properties of the objects you are encoding, not /**/
in some hand edited string.
If you want to include comments about an object, include it in a
property of the object.
If you feel a need to include very detailed breakdowns, write a spec
for the object your passing, it shouldn't be in the data stream.
Your suggestion on wording is really avoiding the issue of why it
should remain when there are other workable alternatives, and
suggesting that it remain part of the standard just because it was
once thought to be useful.
Yahoo! Groups Links
- << Previous post in topic Next post in topic >>