feedback from development (1)

[Richard Jones]

Hi Folks,

Stuart and I are working on implementing a ResourceSync interface for
DSpace as part of the technical development on this project. As I go
along I'm just taking some brief notes on how we got on with the spec
and will feed them back here periodically.

I'm currently working from the 0.5 version of the spec, although I'm
aware that there's a 0.6 version in development somewhere.

This first round of development for me covers building an object model
which can be used to construct and serialise resourcesync documents in
general. Specific documents such as Change Lists or Resource Lists
can therefore be constructed as specialisms of these general document
building classes. So, on to the feedback:

1/ The ResourceSync document model really lends itself very well to an
OO approach. The way that each document is built on the same
structure (sitemapindex or urlset) is very convenient for development.
It has meant constructing a set of base classes for making any kind
of ResourceSync document has been pleasingly straightforward.

2/ From the specification, section 3 has been the most critical so
far. Largely it covers everything that you need to know to build the
base documents. I found myself scrolling up and down it doing a lot
cross-referencing, which suggests - in a very non specific way - that
there might be a better way to structure it; if I come up with a
better structure, I'll let you know, but it's not a serious issue.

3/ Namespaces. It seems that quite a lot of the attributes are in the
atom namespace, but this is not explicitly mentioned in the namespaces
section of the document (1.2). I have taken a very hard-line approach
to use of namespaces in my implementation, giving the attributes all
their proper namespaces based on their provenance from the table in
section 3; the example documents in the specification don't do this,
they leave all the attributes without namespaces.

4/ In some contexts we use an attribute called "modified" to indicate
the last modified date, and in others we use an element called
"lastmod" to indicate a last modified date. These are, indeed, for
different things, but it was confusing enough to have me going back
and forth between document and code to make sure that I was using the
right one in the right place. Could be an argument for using one or
the other name, depending on whether they can be technically
re-purposed, and whether making them the same wouldn't itself cause
other confusions.

5/ Looking ahead to the next part of my development, where I will
produce a class for each type of ResourceSync document (extending from
the base classes that I've written so far), it would be really useful
to have a summary table that indicates the way in which each of these
utilises the ResourceSync document structure. For example, some
fields become mandatory/optional, repeatable/singular, etc. The
information to build that table is certainly already there, but I may
try and construct something quick and easy for a developer to work
from as I get into that next part of the dev, and share it with you to
see if it's of any use.

The code so far can be found at:
https://github.com/CottageLabs/ResourceSyncJava with the appropriate
warnings about it still being very much a work in progress.

Cheers,

Richard


--

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com