On Wed, Dec 30, 2009 at 2:26 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> Robert Haas wrote:
>> On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan <andrew@dunslane.net>
>> wrote:
>>> I think we are getting the cart way before the horse. I'd like to see at
>>> least the outline of an API before we go any further. JSON is, shall we
>>> say,
>>> lightly specified, and doesn't appear to have any equivalent to XPath and
>>> friends, for example. How will we extract values from a JSON object? How
>>> will we be able to set values inside them? In ECMAScript it's not a
>>> problem,
>>> because the objects returned are just like any other objects, but that's
>>> not
>>> the case here. These are the sorts of questions we need to answer before
>>> we
>>> look at any implementation details, I think.
>>>
>>
>> I think the idea that Peter was proposing was to start by creating a
>> type that doesn't necessarily have a lot of operators or functions
>> associated with it, with the thought of adding those later. It would
>> still need to validate the input, of course.
>>
>> Anyhow, that might be a bad way to approach the problem, but I think
>> that's how we got here.
>>
> That does not at all seem like a good way to go. Until we know what
> operations we want to support we have no idea which library to use. We can
> not assume that they will all support what we want to do.
Well that is a bit of a problem, yes...
Doesn't seem insurmountable, though, just one more thing to think
about as we're having this conversation. Someone else will need to
weigh in on this point though, as I don't use JSON in a way that would
make anything beyond validation particularly relevant.
...Robert
