[Ocs] JSON spec

[Laszlo Papp]

>  * i noticed "details='summary'" "details='full'" attribute in
> <person> tag, but not sure what its for. Is theres a spec for the
> person xml (and other data related xml, ie: user, folder, message)
> around ? ..

We also pondered that previously. I am unsure whether we discussed
that at the sprint last year, but I cannot recall anything at least:
http://lists.freedesktop.org/archives/ocs/2011-April/000076.html

> as I understood there from roughly going through the php code.
> * subtags of <meta> becomes top level,
> * things under <data> entries preserve similar representation
> (<personid>user</personid> becomes {'personid':'user'})
> * 'data' is always a list/array, and the top level <person>/<activity>
> tag are dropped.
> am I right / anything else I'm missing?

Disclaimer:  am not a php guru, but: I think, sounds about correct
according to that what I read out of that code. :) I think it is more
or less eligible for what we need.

> 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.

> 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>.

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.

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