In message
<[log in to unmask]>, Mike
Ellis <[log in to unmask]> writes
>
>I'd go lightweight every step of the way. So XML rather than JSON (and
>yes, I know that strictly speaking JSON is "lighter" in terms of KBs,
>but less widely supported). Ditto, REST rather than SOAP. RSS is also
>good (it has the word "simple" in it) :-)
I'm intrigued about the potential of OAI as a delivery mechanism. The
fact that it supports "sets", and the ability to deliver any XML you
like, mean that it could be used for ad hoc querying and the return of
detailed catalogue information, as well as for blind harvesting of DC
metadata.
>The lesson is, simply: create XML renderings of your content if you
>can't build a full featured API. It'll be maybe an extra day of
>developer time, but the benefits are long-standing and very tangible...
... to yourself as well as to others. If you create your content as
XML, you can then style it for delivery as either HTML or PDF (proper
"printable" pages), as well as styling it (maybe to a different XML
representation) for delivery to third parties. Also, if you have a
change of mind about the style of your web presence (not that that ever
happens ;-) ), all you have to do is to change the XSLT and/or CSS
associated with your HTML delivery.
The gotcha with XML is that it is a meta-language. This means that you
can process it (assuming it's actually well-formed XML), but you may not
have a clue about the semantics of what you're processing. Hence the
need for community-wide agreement on XML applications such as SKOS or
the MDA SPECTRUM Interchange Format.
Richard Light
--
Richard Light
SGML/XML and Museum Information Consultancy
[log in to unmask]
**************************************************
For mcg information and to manage your subscription to the list, visit the website at http://www.museumscomputergroup.org.uk
**************************************************
|