repository mountpoints and foxml
Tue, Sep 25, 2007
Now that I’ve plumbed Fedora skeletons into Sakai’s Content Hosting system, I’ve turned the focus onto Fedora, to build up a library of functionality that I can use in Sakai.
It’s just too difficult to develop in Sakai due to the number of restarts required and the sheer length of time it takes to start a full Sakai. I could prolly cut it down a bit but it would still be much slower than doing TDD to build up Fedora client functionality. So that’s what I’m doing. I’m using TDD to build up tests that I can implement to exercise the Fedora web services.
To make it simpler to work with Sakai CHH and Fedora I’ve come up with a small XML schema to describe the special mountpoint XML format. So instead of documents and raw XML I can just use Java objects to navigate the structure. It’s very small but it could get bigger, so an object model is a good idea.
Here’s the schema:
<?xml version=“1.0”?> <schema targetNamespace=“org:sakaiproject:content:chh” xmlns:chh=“org:sakaiproject:content:chh” xmlns=“http://www.w3.org/2001/XMLSchema" elementFormDefault=“qualified” attributeFormDefault=“unqualified” blockDefault=“substitution” version=“2.0”>
<complexType name=“mountPointType”> <attribute name=“endpoint” type=“string”/> <attribute name=“baseHandle” type=“string”/> <attribute name=“searchable” type=“string”/> </complexType>
<element name=“MountPoint” type=“chh:mountPointType” />
and here’s the XMLBeans mapping file to generate more apt class names:
<xb:config xmlns:xb=“http://xml.apache.org/xmlbeans/2004/02/xbean/config" xmlns:chh=“org:sakaiproject:content:chh”>
<xb:namespace uri=“org:sakaiproject:content:chh”> <xb:package>org.sakaiproject.content.chh.beans</xb:package> </xb:namespace>
<xb:qname name=“chh:mountPointType” javaname=“MountPoint”/>
The next set of libraries I’ve now built are the beans to work with the Fedora Object XML format, FOXML. This makes it much much easier to generate XML for ingesting digital objects.
I’ve started getting into the rhythm of either creating or obtaining XML schemata, designing a build system for them and generating Java classes using XMLBeans. The code maintenance and clarity is way beyond what you can achieve compared to working with raw XML. These days, I think it’s positively ludditic to not have an XML schema if you’re working with XML!