Managing your content with XML
Daisy and TeXtML CMSes take differing, yet successful, tacks
Second, a repository includes one or more “navigation documents,” an XML-based specification that defines how users navigate through the repository. There can be more than one navigation document in a repository, effectively allowing you to define multiple repository views. Behind the scenes, navigation documents work their magic by performing a query on the repository. So, for example, one navigation document might arrange the contents by modification date; another, by title.
The Daisy API is a combination of HTTP and XML. In other words, you send commands to the Daisy repository via
HTTP, and those commands are in the form of XML embedded in the HTTP request. Hence, you can control Daisy through just about any scripting language that can “talk” HTTP; you can even handcraft commands by typing in the proper URL. If, however, you’d rather put a more robust API into the repository, Daisy provides a Java wrapper around the HTTP/XML interface.
The DQL (Daisy Query Language) is obviously derived from SQL. A query is a “select” clause, adorned with modifiers for filtering and ordering the results. Whereas in SQL those filters amount to comparisons on column values, in DQL the comparisons are performed on document fields. So, for example, to search for documents in the repository with a PictureContent field equal to “boat,” you would enter the following Daisy query: “select id, name where #PictureContent = ‘boat’.” This returns the ID number and name of the document.
Daisy’s eschewing of a repository structure appears, at first glance, to be a severe omission. Further reflection, however, reveals this weakness as a strength. In a typical CMS, a document is placed into a specific collection within the repository, but that implies a redundancy: Someone has used the document’s content to determine which collection to put the document in. If you’ve properly tagged the document, however, and if your repository server can create a view of the repository derived from those tags, then the equivalent of a collection structure can be rendered at display time. And, unlike collection-based repository servers, such a “view-based” server renders multiple, different views of the same repository. This is exactly what Daisy does, and the result is quite impressive.
TeXtML applies the bulk of its energies to the storage, retrieval, and management of text, and does so by creating an environment awash in XML.
It’s not much of a stretch to say that TeXtML takes text documents from our universe, maps them into their equivalents in an XML universe, and uses the capabilities of that universe to provide search and management functions that would not be available otherwise. (This is not to suggest that TeXtML can handle text-only docs:
It can easily store and retrieve documents with embedded binary data.)
TeXtML uses a collections paradigm for organizing documents. Collections appear as named folders on TeXtML’s administration console, and are navigated using the standard path constructs that anyone familiar with a file system would recognize.