On Mon, Jun 6, 2011 at 8:48 AM, Sean Coates <s...@seancoates.com> wrote:
>
> I was careful in the RFC to indicate that this is *not* JSON, but if others
> feel as strongly as you do about the use of this term, I think it can be
> removed without hurting the idea (as you indicated).
>
Still, it is mentioned so many times that it could be unintentionally
misleading IMHO.
>
> You're right that the RFC does not declare a syntax that will always
> validate as JSON, nor does it respect serialization rules, but I see it more
> as a declaration syntax than a serialization format, as it is proposed. The
> real goal is to improve interaction with third parties, which I think the
> proposed syntax would allow.
>
> That said, other than the \u syntax, I believe that the proposed
> declaration syntax would still allow JSON from a third party to me
> interpreted by PHP, in a way that makes sense in PHP.
>
Can you provide an use case and code example of how that would look?
>
> > Somewhat on a side note, I do not understand the statement that
> >
> > "using a strict syntax would not conform with the PHP way"
> >
> > or at least how it relates to this RFC.
>
> This is directly related to the JSON-non-strictness that everyone seems to
> want (me included). For example the following is completely invalid in JSON,
> but normally OK (for small values of OK) in PHP:
>
> (not-)JSON: {foo: 1}
> (not-)JSON: {'foo': 1}
> PHP: array(foo => 1)
> PHP: array('foo' => 1)
>
> (For anyone who doesn't follow, correct way in JSON is to use " not '.)
>
> Thanks for the comments.
>
As mentioned earlier, I think the resemblance to JSON is just a happy
coincidence, the syntax makes enough sense by itself. You can argument that
its familiarity/friendliness/ubiquity makes it a good option, but in its
current state (i.e. not defining why JSON compatibility is justified) I'd
say it is not complete.
Regards,
David
