On 28/11/2008, at 5:02 PM, Paul Davis wrote:
On Fri, Nov 28, 2008 at 12:13 AM, Antony Blakey <[EMAIL PROTECTED]
> wrote:
On 28/11/2008, at 4:08 PM, Paul Davis wrote:
Any JSON diff format is going to require the JSON RFC's 'SHOULD' to
either be changed to a 'MAY' or 'MUST'. The ambiguity in 'SHOULD' is
going to cause problems.
That "SHOULD" is dominated by the preceding statement that "A JSON
text is a
serialized object or array", so it is effectively a "MUST" because
the spec
doesn't allow for any other possibility. IMO the JSON spec is not
ambiguous
in respect of this issue.
I fail to see how "A JSON text is a serialized object or array" in any
way dictates that object member names must be unique. Obviously to see
such an interpretation we have to ignore 99% of the current JSON
implementations that assume JSON object member names are unique, but
still, a strict reading of the spec allows non unique member names.
And as I said, the current JSON dserializer that couchdb uses allows
for non-unique member names (but only ever operates on the first).
Because of this:
"The terms "object" and "array" come from the conventions of
JavaScript."
Javascript objects have unique field names. Combine that with this:
"A JSON text is a serialized object or array."
and it means that a valid JSON text IS the serialization of a
javascript object or array, and hence cannot contain hashes with
duplicate names. It is not that a duplicate name is allowed but
resolved according to some operational convention (first or last name
wins), but rather that a JSON text that contains a hash with a
duplicate name is not a valid JSON document because it cannot be the
serialization of a javascript object.
For sure. My point is that a JSON-community driven diff might
presume that
Javascript expressions (as in JSONPath) are OK, and hence assume
you would
use "@.length - 1". The context of the JSON community is not
necessarily
Couch's context.
Here we're totally in agreement. We should yell and scream at the JSON
community for being shortsighted int their ideas of requiring a full
JavaScript engine to evaluate their RFC's. That's not to say we don't
want them on our side though. Perhaps it should be more of a subtle
coup d'état in how we approach making a diff spec.
Well, how about we define one, and submit it as a RFC. It doesn't have
to go through the JSON community. If a different community wants to
extend that RFC, allowing for profiles e.g. JSONDiff profile 0 => no
expressions, JSONDiff profile 1 => assume a javascript interpreter.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Did you hear about the Buddhist who refused Novocain during a root
canal?
His goal: transcend dental medication.
