darcusblog

I’ve been thinking about how and whether to integrate CSL into OpenDocument. Right now the design of CSL is quite apart from OD. Everything in CSL, for example, is in its own namespace, and I’ve not tried to take advantage of the FO-based styling infrastructure in OD. Also, my primary design goal was a good–easy-to-author-and-validate–xml language. Compactness and performance were not priorities. So while I rely on elements for a lot of content, and tend to nest structures, OD tends to rely more on attributes.

It’s within that context that I’ve thought about refactoring the design a bit to fit better within a context like OD. As I have also always had in mind the need for GUI editors (including HTML-based versions) for the language, I’ve been wondering how easy some aspects of CSL are to handle from that perspective.

Enter Johan Kool, who has been chatting with me about some of this on the project list. Johan did the smart thing; rather than talk about it, he decided to open Interface Builder and start mocking up a GUI! I had done some simple playing around with HTML awhile back, and came up with examples like this:

         

                     

Johan has gone a bit farther, though. Here’s his first stab at some windows. First up is the metadata panel:

         

                     

And here are the generic formatting panels.

         

                     

Nice to see that the XML design gave a good hint towards a GUI, since this is pretty much what I was visualizing as I was designing it.

The tricky part of handling the style configuration in a GUI is how to handle the nesting that is a fundamental part of citations, and of the CSL design. Here’s Johan’s first attempt:

         

                     

The problem here is it doesn’t handle the nesting within formatting blocks. For example, in CSL currently, creator is split between names and roles. While I could move CSL to a flat model, that introduces other problems. Additionally, something I didn’t attempt in my HTML mockup was a way to assign styling to those individuals chunks. So how about this?

           

Seems promising to me!

Update: from the comments, Johan seems to have had an epiphany that resulted in this:

This is definitely a simpler way to go.

As the OpenDocument TC contemplates supporting RDF for document metadata, I am talking to them about upgrading the bibliographic support. I have been arguing that the two ought to be considered together, and that it makes sense to start to think about a comprehensive metadata approach in OD: one where the same framework is used to represent not just the document as a whole, but also embedded parts, such as figures, or images, or bibliographic references.

So how might this work?

OpenDocument is fundamentally an XML file format, so if it supports RDF, it’s important that it does so in a way that’s still amenable to XML processing. Yet the XML RDF syntax is so flexible that it makes XML processing rather difficult. So perhaps as a first principle, we ought to adopt an approach something like in DOAP and say that OD ought to support a constrained subset of RDF, where the syntax is clean XML, which is also happens to be RDF.

It turns out RELAX NG is nicely suited to handling the RDF model, with its ability to handle unordered content (the interleave feature), and so forth. So let’s say we define a clean RDF subset in RELAX NG. Let’s further say that we include support for Dublin Core in that base metadata schema.

Now, what about bibliographic metadata? A more traditional approach would define an entire standalone schema. This is the MODS approach. Yet that makes little sense in this context, so instead we include the base schema, override some of the structural definitions to allow citation-specific typing and add additional metadata properties. Otherwise, however, we use the same core metadata properties as are in the document metadata support. Because we are using the RDF model, adding new namespaced content is easy and predictable, and we now have a nice balance of flexibility backed up by the rigor of an underlying model.

The view from my xml editor:

[update: I've just posted the schemas here in case anyone is interested. They're just for demo, but include one that does generic constrained RDF validation, another for a core set of metadata, and the last a bib schema that customizes the second. The archive includes two example instances that are valid against the first and the third. In contrast to Adobe's XMP, I add what for me are essentials like support for xml literals (think, for example, embedded MathML in titles and abstracs) and at least basic support for rdf:type, while removing rdf:Alt and rdf:Bag, as well as the restriction that all resource must be wrapped in an rdf:Description element.]