[Ocs] JSON spec

[Mohd Izhar Firdaus Ismail]

On Fri, Feb 10, 2012 at 8:19 PM, Laszlo Papp <lpapp at kde.org> wrote:
>
>> programming wise, to me at least, its easier and faster to deal with
>> json than xml as its very close to native types especially in python
>> (dictionary), ruby (hash), php (key-value array), javascript ..
>
> Valid point for some people, I agree. That makes me think that we
> might need to deal with the tagattributes as well in order to not lose
> any data, if one customer, like you, would just like to focus on the
> json bits.
>
>> though if ocs is choosing non-interchangeable format, there should be
>> a full specification on the json format so that all data is
>> represented. or a specification on how to transform the xml to a ocs
>> json ..
>
> It is not a problem to write a converting tool if we go with some
> custom logic not existing out there yet. It is not the main focus for
> now.
>

agree ..

>> what i noticed disappeared in the php json is -> 'details' attribute
>> in <person details="full"> is lost. also. I'm not sure how the loss of
>> that info will affect the clients, but loss of <meta> and <ocs> should
>> be fine i think  ...
>
> They are indeed gone. I am not sure about the reasons; maybe the
> details tag attribute is not documented or decided yet how to work in
> all aspects, or just obsolete ? Anyway, it does not matter as far as
> we need to consider attributes like for the images, as you said.
>
> What about just add the attributes as key/value pairs ?
>
> For instance if you have:
> <icon width="100"></icon> just treat it as it was
> <icon><width>100</width></icon>.

how about <icon width="100" height="100">http://site/icon.jpg</icon> :) ?

anyway, I suggest to just define in the spec that icon json should
follow this format
{'width':100, 'height': 100, 'href': 'http://site.icon.jpg'} instead
describing how to flatten the xml.

>
> Most of the time there is no need to make distinction whether the data
> comes from attribute or element value when serializing into json. I
> mean if you had:
> <foo bar="x"><bar>y</bar></foo> you could not flatten them in same way
> in json since you would have two "bar" keys under foo. If there are no
> collisions like that, it is alright. In that corner case, you could
> use something like this:
> {"foo": {"attribs": {"bar": "x"}}, "children": {"bar": "y"}}, but it
> is super verbose and uncomfortable to use. :) In such corner cases, if
> at all, we can do something different, whereas i ca not think of a
> single situation where i have ever had an element with identical
> attribute name as a direct child element tag name.

yep, though I think its easier to just avoid having such cases
altogether in future specs. I didnt notice any clash in current spec.

>
> Speaking of the reference implementation: would that option be
> possible to put it under VCS ?
> http://www.socialdesktop.org/library/lib_ocs.txt
>
> Best Regards,
> Laszlo Papp

-- 
Mohd Izhar Firdaus Bin Ismail / KageSenshi
Inigo Consulting (FOSS/Plone Development, Training & Services)
http://www.inigo-tech.com
Fedora Malaysia Contributor & Ambassador
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331