On 2/11/07, David Karger <[EMAIL PROTECTED]> wrote: > > While written with the intention of being self sustained, I think it > > should work great without any schema data
(I should have completed that sentence "...embedded in the HTML of the table, but instead kept in a separate place, such as a schema.js file on the side", to clarify how I interpreted the question and what my answer was about. :-) > > but the ex:type attribute on > > the table tag itself, denoting what type of data the table contains, > > allowing the rest to sit in your schema files. (And even that > > attribute is optional, if you for some reason prefer to add a column > > named "type", keeping the same value for every row. I personally find > > that uncalled-for verbosity, but it is certainly supported.) > > agreed. on the other hand it might be useful to make sure that an > analogue to the json schema file can be done in the html table---for > example, that properties like pluralLabel that appear in a json schema > file could also appear in the table---eg as attributes of the header row > of the table. All of the above is presently supported. > I think you may have misunderstood my example. My thinking was not > that the same data appeared three different ways, but rather that three > _different_ blobs of data were represented three different ways. Ah. Well, whether intended or not, I found the other mode of thought useful too, and bringing a fresh thought to the table. (I did not stop to consider the intended example since it is, to the best of my knowledge, how Exhibit has already behaved ever since I first started picking up on it.) > if these are all about the same data, it isn't clear to me that there is > value to having all the alternate links---it isn't like the use of alt > in html which suggests different ways to display info by differently > abled browsers; clearly anything that can handle the data in one syntax > can handle it in any syntax. Um, no? It's more like languages. I have excellent native support for Swedish, great support for English, rudimentary support for French and even less Japanese. I don't speak a word of Lebanese, but some people do. Web citizens like browsers and search engine spiders are much the same, but with data formats. Exhibit might handle all these syntaxes, but were it only for the benefit of Exhibit we put them there there wouldn't be call for anything beyond json in the first place. > I agree that we want to use naming to be able to address multiple > exhibits running on the same page. However, this should work regardless > of the data syntax---not only for data represented as tables. We are good at trying to make the same point, but not quite get through with it. :-) At least we are very much in agreement here. :-) > So, we want to separate being able to name a particular blob of data (eg a > particular table or file) from being able to specify which names appear > inside a given xibit. Now I might be lost, though. The only problem I raised and wanted to solve here is to tie all separate data sources listed in to a specific exhibit (or possibly multiple exhibits; they might, for instance, want to share some schema files and data subsets). Names were borrowed from CSS as an example of a way to achieve that. I think what I say is that I care for the latter issue. I think my mentioning the HTML title attribute might have invited a whole can of worms in the opportunities for miscommunications department; let me withdraw that wording again. :-) > I think the easy approach is the one taken now---xibit loads whatever it > succeeds in loading, and if there are duplicate data then you get > duplicates in the xibit. Your data, your mess :) As long as we settle for that, I think this line of thought (raised by my initial misunderstanding of your example) is effectively put on ice. And even though I liked it, I'll gladly leave there for quite some time still, until the issue starts arising in real-world situations, and not just show up here on the drawing board. (As I myself primarily care about wiring up Exhibits, over catering non-interactive or non-browser user agents.) -- / Johan Sundström, http://ecmanaut.blogspot.com/ _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
