On 2/8/07, David Karger <[EMAIL PROTECTED]> wrote: > So, it makes sense to put the data in the page as "rigidly structured" > html---something that can be parsed rather than scraped. There are > several options here: an html table, a microformat, or just a blob of > json. I like the json better because it is less verbose, not full of > fiddly brackets and tags. But if I want my document to be legal html > then I will have to start using html escapes for some of the symbols > that are perfectly normal in json; this will be annoying and mean the > embedded json isn't legal json.
Or use CDATA blocks, which makes you only have to escape ]]> occurrences which, while perfectly normal in json, are at least not very common. You would mostly never have to quote those in real-world use. > As I've argued before, there's no reason to pick here: with the > previously mentioned army of programmers, we could support parsing of > _all_ the formats I mention above. Agreed. It wouldn't take much of an army either; one or two hackers with the right itches is all it takes. And they will surely come too, once they figure out about all the ultra-neat things Exhibit can do for them, and how. > However, there is one flaw in the above approach, that leaves me still > interested in the idea of just letting xibit render the page and > snapshotting the result. As an exhibit gets big, one natural way to > control its complexity is to have _multiple_ data files---eg one for a > schema that you reuse on multiple exhibits, another for data of type 1, > another for data of type 2, another with lat/long data collected from > the googlemaps API. Under the above scheme I will have to take all > those files and mush them into the single exhibit html page. Since this > loses all my organization, obviously this mushed up data won't be my > primary copy. Rather, I'll have separate files, I'll add new data to > them, and I'll have some manual or automated process for reconstructing > the all-in-one-page exhibit. I get the impression that you are talking about freezing the rendered form of an Exhibit here, even if it is not statedly so. Freezing a snapshot of the complete inner data world of an Exhibit won't require that once we get further with our Exhibit exporters, which I am fairly sure will soon have the capacity to export the full exhibit data set, rather than just what is in plain view. (I am sure we will get it mostly because I want that myself and am prepared to eventually write the code for it myself, if necessary. :-) -- / Johan Sundström, http://ecmanaut.blogspot.com/ _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
