W dniu 27.03.2012 17:11, Paul Sokolovsky pisze:
On Tue, 27 Mar 2012 09:22:30 -0500 Andy Doan andy.doan@linaro.org wrote:
On 03/27/2012 06:32 AM, Paul Sokolovsky wrote:
So, I would like to propose alternative syntax solving the issues above. I probably should start with saying that if the talk is about LAVA, then using native LAVA JSON request immediately comes to mind. Well, I guess human-writability wasn't a design goal for that, so I skip it. It still makes sense to stick to general-purpose hierarchical structure syntax though. Except that JSON has 2 problems: a) it doesn't support comments natively, so we'll need to pre-process
I'm fine with the overall idea, but I'm not a big fan of adding support for comments for two reasons.
- are these files really so exotic they need comments. ie:
Well, don't even let me start to rant how stupid was for JSON founding fathers to explicitly exclude comment support ;-). My logic though would be very simple: it's human readable, so excluding humans from its processors was really unwise. Well, even CPU vendors include NOP in instruction sets, not saying that "LD A,A" or "JMP $+N" should be enough for fillers.
I'm with Paul on this one, JSON with comments would be more valuable and would be not that distant from the origin, javascript. That's why I suggested to add comment support to our parser (even though that would make it non-standard.
Without comments JSON can be easily edited non-destructively with minimal delta. With comments the nice hierarchical data structure turns to an ugly tree of nodes that, just like {X,HT}ML. Anyway....
Personally I think that JSON is not very friendly for writing because it is so raw. Programmers like to simplify stuff for our minds but often that simplification requires bigger and more complicated parsing logic. I see the value of JSON it its simplicity and ubiquity. Ideally people would be using an understandable web editor that stores the test scenario as JSON but that's something nobody really bothers to look at.
Thanks ZK