>>
Do you have any preferred means of access, by the way? Any technology
you particularly favour? Would you want, say, a JSON interface, or are
you happy with RSS returned (to browser or server) in response to a
query? Or something else - some specific metadata format for object
data, say?
>>
I would agree with Mike and say that for exhibit display purposes its
best to go with
simple and standard access. XML is good because almost anything can
read it but it has to be well documented. I wouldn't go with JSON as
it seems more complex than necessary.
RSS is ok as it goes but you have to realise that all you really get
is a headline, a summary and a link to a
web page. People do put other information in their RSS feeds but
there's lots of competing standards and lots of sites end up
embedding HTML code which is fine if you're looking at it on a
browser but no good at all for other uses.
Mike's also right to say that you can build in mechanisms to cache
the content which can smooth over small problems but it's still
important to inform users of changes and keep the data format well
validated. Here's a couple of examples why this is important.
- For one news feed exhibit I was involved in we implemented a cache
to smooth over any small glitches. So when the provider changed the
format of their data without telling us the exhibit continued for
another 3 months without museum staff noticing even though the
exhibit wasn't updating the news.
- Similarly for another exhibit the news provider was generating the
XML by hand. One story contained a glitch which invalidated the XML.
This wasn't a problem for the provider because most of their audience
view the feed in browsers which ignored the problem. Our exhibit
however double checked all the data for validity, decided that the
data was invalid and didn't show any updates for two weeks until the
offending story had gone.
It sounds like the system Mike is describing puts everything in XML
and makes the API the core of the main site as well. This sounds like
an ideal solution - that way the provider doesn't have to create
everything twice and they're much more likely to notice problems with
the API as it will also affect their main site.
Cheers
Joe
**************************************************
For mcg information and to manage your subscription to the list, visit the website at http://www.museumscomputergroup.org.uk
**************************************************
|