Johan Sundström wrote:
> [snip]
> One thing your whole line of thought -- alternate formats provided
> with the same data -- seems to lack is picking a favourite. Which one
> is authoritative? As soon as you have data in duplicate (or more)
> copies, you have synchronization issues (as the data maintainer) and
> canonization or importing uniquifying issues (as the data consumer, i
> e the Exhibit code base). I will focus on the latter. Your examples
> will all have Exhibit load all of the data files, fetch the data three
> or four times and (I guess) end up with four items per intended item
> in its presentation mode, which is neither what you wanted nor
> resource conservation intelligent.
>
I actually didn't mean those different links to point to the same data.
The example was meant to show pulling different data from different
sources. The hope is that people can more easily "borrow" other people's
data... I was told that's called "transclusion."
http://en.wikipedia.org/wiki/Transclusion
> I would propose picking one of the data formats linked as the
> authoritative one (for Exhibit itself, or the browser, as it gains the
> support natively) and marking the others as alternate, similar to how
> you can provide ten different-looking stylesheets for visitors to
> choose among while only picking one of them for presentation by
> default. rel="alternate" is the standard procedure, so I would like to
> decorate your example into:
>
> <link rel="exhibit-data" type="application/json"
> href="my-data.json" />
> <link rel="exhibit-data alternate" type="application/rdf+xml"
> href="rdf-xml-blob.rdf" />
> <link rel="exhibit-data alternate" type="application/n3"
> href="n3-blob.n3" />
>
> and perhaps toss in a rel="alternate" attribute on the <table> tag
> presumed present in the page too, given your original query. The above
> would render Exhibit only load and process my-data.json and ignore the
> rest (or, assuming there is some load error with that and we are
> sophisticated enough to keep trying the list until we run out of
> alternatives, the others, one at a time, until we succeed with one).
>
... but what you suggested seems like a great thing to have, too.
> All reasoning so far assumes a single data source, one data set per
> tag. The <link>:ed resources above all (I believe) may contain a full
> data set, including multiple typed subjects per file, full schema data
> and so on. The table format can't (requiring one tag per type of
> subjects -- as html tables are only two-dimensional and each type
> needs a separate set of header cells for naming its properties) and
> presently requires one tag per type. Still, in either case it is often
> useful to actually split up data into multiple resources you include
> separately.
>
> This creates the issue of dividing resources into equivalence classes,
> demarcating resources as belonging to one format, the total sum of
> each equivalence class summing up to the complete exhibit. CSS uses
> the title attribute to, if you will, add a unique id property for each
> data set; I think we ought to as well. Ideally we should tie this id
> to a specific Exhibit instance in the page, too (as we should support
> multiple exhibit instances running in parallell on a single web page,
> IMO -- we do now, anyway). I would find it pretty if this title
> attribute is the name of the javascript variable that references the
> Exhibit in question (but if we want something else we can certainly
> add a level of indirection).
>
> (If we decide on trying to be intelligent about trying multiple
> options for loading an exhibit, if some of the resources making up the
> authoritative version linked fail, we add some complications and
> implementation overhead in a transactions system to roll out the
> incomplete exhibit data set and try the next -- as each alternate data
> set might have been split up into multiple resources in different ways
> and we have no way of knowing what parts of one map to what parts of
> another.)
>
This sounds a bit complicated. I have a feeling that each exhibit author
isn't going to bother creating multiple equivalence classes.
>> <body ex:ondataload="do something with 'database' variable">
>> ...
>> </body>
>> </html>
>>
>> You don't have to have ex:ondataload. By default, that will be a handler
>> for constructing an exhibit. But if you have it, then you can do custom
>> things with 'database'.
>>
> I agree. It is also only useful for the use case "a single exhibit
> instance running in the page", which will of course be the most common
> case.
>
> With some of the uncoupling ideas tossed about for future versions of
> Exhibit, it might even be a good design only allowing single instance
> operation, though I have a feeling there would still be situations
> where namespacing different exhibits into their own containers is
> useful.
>
The "database" variable and the ex:ondataload event handler can be baits
for Javascript programmers (not non-programmers) to adopt Exhibit, even
if they have no need for the presentation engine at first. The uncoupled
UI components are the next baits, letting those programmers drop in
little widgets that bind to "database" through some queries. It's like
programming Microsoft Access forms. Those uncoupled UI components also
make it easier to embed exhibits within blogs and wikis.
David
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
