MCN 2006 Conference Presentation Notes

Encode Once, Access Many: Using the Power of XML to Present Museum Information

Nov 10, 2006, 8:30 - 10:00

Moderator/Presenter: Mary W. Elings, The Bancroft Library, University of California, Berkeley
Participants: Brent Gustafson, Walker Art Center, and Karim Boughida, Getty Research Institute

XML technology is a powerful tool in providing access to information. This panel will look at how XML provides museums with flexibility and cost efficiency in presenting information for institutions as a whole and for individual collection materials and assets. Panelists will discuss how the various types of information in XML can be encoded once and accessed many times via methods such as XHTML/HTML, OAI, interactive Flash pieces, RSS news feeds, email newsletters, dynamic signage in galleries, interactive telephony applications, etc. The panel will look at CDWA Lite, a developing XML schema coming out of the museum community that will further use of XML by cultural heritage institutions and provide increased access to cultural heritage information.

Presentation Notes

• Thank you for coming, introduce yourself
  • Briefly get feel for participants' experience and expectations
    • How many of you are working with XML?
    • Anyone not? If not, will they in the future?
• Main Presentation
  • Talk about how we ended up using XML for our data output at the Walker
    • Main decision stemmed from a change in development process
    • Old site had static files, framesets, non-dynamic content. A big mess for updates and maintenance.
  • What tech to move to?
    • Stick with static files
    • Mason (embedded PERL) (old dev knew this well, we didn't)
    • PHP (embedded) (popular, everyone would have to learn it)
    • XML/XSLT (transformation paradigm) (From Brent's previous job)
      • Appservers
        • Axkit
        • Cocoon (JSP)
  • Brief overview of how various other systems work compared to Axkit
    • How flat HTML files work
    • More advanced PHP / CFM / JSP
    • The basic AxKit model
  • We chose XML/XSLT, Axkit
    1. XSL in general fit our team size and skills and naturally matched our institutional goals.
    2. Was open source, which we support
    3. Allowed multiple forms of output from the same data very easily
    4. By being so XML-centric we have incredible flexiblity for the future and new products / technology.
    5. XSL transforms one XML schema into another XML schema, future proof.
    6. Extended Axkit diagram with multiple output/input
       • One WAC page can be used by multiple XSL files for different styling of the same data
       • One WAC page can generate different XML for different output devices that requre it
       • One XSL stylesheet can be used by different WAC pages for similar presentation with different XML data.
       • One side does not affect the other as long as the XML stays the same.
       • XSL can be written and not interfere with logic. Logic can be rewritten (even a switch to a totally different language) and not affect presentation.
  1. Implementation
     1. Calendar
        1. Central repository for all event data
        2. Same data being used in calendar and Flash movies. XML is providing image info and link info
        3. Flash useds same XML as HTML page, but parses in it's own way
     2. Film/Video
        1. Event data again being pulled from the same record as Calendar
        2. App logic is the same, so is the XML, zero changes. Just chance the XSL and you get a different layout tailored to that audience.
     3. RSS
        1. We can also send data in streams other than a web browser
        2. Extremely easy to impliment because it's XML
        3. Again, same data, this time different output.
     4. iCal
        1. iCal and many calendar apps use .ics files for data
        2. They're simply XML so it's just as simple for us to make an iCal subscription to our Calendar
     5. iPod
        1. We have cell phone audio tours, called Art on Call.
        2. We also have a version for iPods, which we have for checkout in the galleries.
        3. iPods accept iCal calendars, so it's a natural fit we include this on our audio tour iPods.
        4. They're simply XML so it's just as simple for us to make an iCal subscription to our Calendar on each iPod.
        5. Auto updated when they're recharged, through iTunes.
     6. Art on Call
        1. XML in XML
        2. RSS embedded into regular schema in RSS node
        3. No real work, just importing
        4. Can use it to add content to pages from two separate CMS's
        5. Easily add related links to calendar from blog
        6. No work on designers side, this time all on dev.
     7. HTML e-mail
        1. Data again from calendar database
        2. Application logic has very little changed. Adds in ability to make a custom statement.
        3. Presentation logic changed, so most work was only on design side
     8. Admin
        1. What to do for CMS?
        2. Buy something expensive? No.
        3. Build our own, but with what? Same problems as before (PHP, JSP, etc?)
        4. Use XSL/XML!
     9. Everywhere else
        1. Using it a ton of other places on the website, and can extend what we've done in the future for just about anything that uses XML.
  2. What didn't work
     • Interactive signage. Issue with 3rd part software and import.
       • Thankfully this is something we can fix in the future with hardware upgrades
     • Ticketing. Same issue, 3rd party software, doesn't easily allow import and display.
     • In Design?, and Walker Calendar Magazine. Does allow XML import, but not in the way that works the way we would need.

Mcn 06 Links