[uf-dev] JSON serialization of microformats

[Jim Wilson]

Hi Dimitri,

> While this is indeed clever, it requires branching for the reader of the
> resulting JSON, albeit a very easy one. It seems that if the value can
> be plural, it should be always wrapped into an array.

Personally (and this is just my opinion) I don't like that.  In order
to enforce such a rule, you have to know in advance whether any
particular thing can or cannot be plural - which would seem to be
context specific.

Also, what does that say about when something can be plural but there
are none of them? Should it be an empty array?  Should it be null?
Should the value even be represented as a key in the parent hash?

I'd like to see the JSON representations stay flexible and expect the
consumer to deal with reasonable variability.

> But ultimately, both Mike and I feel that this should
> be agreed upon and documented on the wiki to let developers of JSON
> producers and consumers be on the same page.

Agreed - sounds like a good idea!  Perhaps a discussion page is in order?

-- Jim R. Wilson (jimbojw)

On 10/4/07, Dimitri Glazkov <dimitri.glazkov at gmail.com> wrote:
> Just had a brief conversation on IRC w/Mike, and I agree with him
> (Mike, feel free to object if I am putting words in your mouth). We
> need to set some guidelines (standard?) on JSON serialization of
> microformats. This has been an issue of minimal importance when JSON
> intersection was limited to test cases, but with arrival of Optimus,
> the mass has shifted.
>
> For instance, currently Optimus (Dmitry, this is no knock against you
> or the product), will intelligently substitute values for arrays if
> there is more than one value detected. For instance, hcard: {} will
> become hcard: [ {}, ... ] if there is more than one hcard. While this
> is indeed clever, it requires branching for the reader of the
> resulting JSON, albeit a very easy one.
>
> It seems that if the value can be plural, it should be always wrapped
> into an array. But ultimately, both Mike and I feel that this should
> be agreed upon and documented on the wiki to let developers of JSON
> producers and consumers be on the same page. I'd be happy to get the
> process started, documenting existing behavior based on test cases and
> Optimus output, provided we have consensus on utility of the endeavor.
>
> What are your thoughts on this?
>
> :DG<
> _______________________________________________
> microformats-dev mailing list
> microformats-dev at microformats.org
> http://microformats.org/mailman/listinfo/microformats-dev
>