On 2/9/07, David Karger <[EMAIL PROTECTED]> wrote: > Johan, I've finally looked at your embedded-table exhibit. Very nice > work. It certainly accomplishes the goal of presenting the data to > google. The only thing that concerns me as an author is that, as you > say, the html is not particularly self describing. So if I edit it by > hand, I am liable to make a mess of my data by, e.g., leaving out a > blank column entry where some data is missing, and thus shifting all the > values to the wrong properties. And I won't even see the problem unless > I careful read the rendered exhibit.
A similar argument can be made against separating schema and data, by the way. I'm not saying it's wrong (I rather love the option), but the risk of skew usually increases when you add distance between where schema is defined and where the data you input that should match it, are located. These are issues users should have to deal with IMO; Exhibit would end up a child-safe piece of useless junk if we traded off this functionality for something that would guarantee bailing out on errors in the data. As you say, the data overhead of introducing layer upon layer of parity checks would likely only serve to piss people off rather than help anyone do anything btter. > One way around this would be to continue using json as the authoratative > copy, but then use html table as the "presentation copy". I think this > would be a good thing to hang off the "copy all" button: suppose that to > the current list of RDF/XML, Semantic WikiText, Exhibit JSON, and > Tab-Separated Values, we added a fifth option of "HTML tables" (I use > the plural because I think that, as in your exhibit, one table per type > is desirable). Very good suggestion; I'll certainly heed it. I never thought twice about the name, to be honest, but yours makes more sense for what I was going to implement. (And it doesn't matter much when the output is really only one table, either.) > I'm not sure whether it is better to output just the tables, or to output a > complete web page containing the tables. But either way, I could > continue to edit (and look at on the web) a "staging" copy of the exhibit, > and then paste my tables into a presentation copy. I don't find it any different from the other exporters; export to JSON gives only the data and not the required presentational HTML needed to render it, and neither do I think table export should. The complete layout of the HTML page should be left up to the web designer. But we could certainly add another option (to all export formats) of generating a full "bare-bones" exhibit HTML page runnable by pasting it into one or more files. We are discussing a few other orthogonal switches for the export output on the dev list; this could certainly be another one we just didn't think of ourselves yet. It would help make Exhibit accessible to people without having to understand too much of it, except for purposes of improving its presentation. -- / Johan Sundström, http://ecmanaut.blogspot.com/ _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
