I like your thinking, David. Below I'm sorting out additional problems
I think we should, if not even must, address and solve to make it work
well in practice.
> David Karger wrote:
> > one other question about your method: can I combine it with the standard
> > method? eg put a pointer to some schema in a link from the head while
> > putting actual data into the html table?
While written with the intention of being self sustained, I think it
should work great without any schema data 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.)
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 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).
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.)
> <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.
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
