incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: partial/diff updates?
Date Fri, 28 Nov 2008 10:04:04 GMT

On 28/11/2008, at 5:02 PM, Paul Davis wrote:

> On Fri, Nov 28, 2008 at 12:13 AM, Antony Blakey <antony.blakey@gmail.com 
> > 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.



Mime
View raw message