On 3/26/07, David Karger <[EMAIL PROTECTED]> wrote: > A little followup to this old thread. Suppose we accept that computed > facets are a good thing as data manipulation (you say "I consider > computed facets something Exhibit does in the data input stage") then > perhaps the place to define the computed facets is as _computed > properties_ in the _json file_, rather than as something in the html > file. This is appealing because, for example, we could use arbitrary > javascript code to compute the facets, and it would feel fine since it > is already a js file.
Formalia: the "in the js file" phrasing is more appropriate here than "in the json file", as the json is (more or less) defined as the javascript literal syntax, i e no function definitions, invocations, and assignment. (This is an important distinction to make, so we don't taint / water out the json name to become yet another meaningless term.) My experiences with turing complete data sets (or configuration files, such as sendmail.cf and the many small domain specific languages breeding in the config files of the ruby world, for instance) are that the solution invites many problems too. That is probably neither argument for nor against having computed properties with the computation specified inline (in the data set), which likely (?) is just a subset of the issues incurred by having the computations specified out of band. Looking at this from a mashup point of view, where your data is not your own, your suggestion of having computations inline presents no solution to the problems at hand, which out of band input converters do. -- / Johan Sundström, http://ecmanaut.blogspot.com/ _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
