[occi-wg] Simple JSON rendering for OCCI

Tue May 12 17:32:12 CDT 2009

On Tue, May 12, 2009 at 2:23 PM, Tim Bray <Tim.Bray at sun.com> wrote:

>
>  .NET, http://www.google.com/search?q=json%20.net
>  turns up lots of stuff including from Microsoft's own Codeplex.

There's even native support for JSON inside of Silverlight[1] which for a
company as XML-heavy as MSFT says quite a bit.

Javascript/Python/Ruby, no problem.  PHP I have no first-hand info,
> but since half the Ajax-heavy sites in the planet are PHP-backed, I
> can't imagine it's an issue.   -T

Yup.  At this stage of the game when to use JSON and when to use XML for
data serialization comes down to some pretty basic rules:

* If you're working with:

    * Mixed content (e.g. this is <i>an example</i> of mixed
<strong>content</strong>),
    * Mixed vocabularies (e.g. <foo xmlns="http://example.com/foo"
xmlns:bar="http://example.com/foo/bar"><bar:baz/></foo>)
    * Data which requires schema-based validation (e.g.
<html><body><head><title>This is illegal</title></head></body></html>)

...  you're only option is XML.

* If you're working with:

    * Structured data (e.g. { name: "foo", bar: "Yes please!" } )
    * Data from one or more sources that can happily coexist within a single
namespace (e.g. { name: "foo", bar: "Yes please!", baz: [1, 2, 3] } )
    * Data that doesn't require schema-based validation (e.g. { baz: [1, 2,
3], bar: "Yes please!", name: "foo" } )

Then use the format that is easier to work with from a developers
perspective for the use case at hand.  In most cases that means JSON, at
least from a web development perspective, as you tend to be working directly
with the data as is w/o need for further filtering and/or transformation. In
/some/ cases that means XML as it /does/ require further filtering and/or
transformation into something else.

For the record, as big of a believer I am in the fact that XSLT actually
/does/ cure cancer, from my own perspective when you're not required to use
XML for the reasons mentioned above and yet you choose to just because it
can easily be transformed into something else via XSLT you're making the
wrong decision. Use JSON and if you find yourself in a situation where you
actually need the power of XSLT to transform and/or filter the data
represented by the JSON object, write a recursive function that converts the
JSON object into a DOM object to then transform and/or filter it as you best
see fit.

Just my two cents.

[1]
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.json(VS.95).aspx

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |
http://broadcast.oreilly.com/m-david-peterson/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090512/d948126a/attachment.html 