Doing a lot of background reading in preparation both for the next phase of the project (more formal publication of the dictionary interface and data) and a proposed article. Most notes are on the printouts of articles, but key points are:

• I must implement an OAI-PMH interface for the dictionary. There are good examples available through OLAC (where we should also be registering the dictionary when it's publicly usable). The mechanics of this are not complicated, but we don't yet have the metadata in a usable form.
• Each entry should have a single-URL access point, so that it can be cited. There should also be a link for citing it.
• For citation, we need versioning. After considering a range of options, we decided that the best way to provide it is this: whenever an entry is retrieved, it has a "cite me" link on it, and that retrieves a formal citation pointing to the entry, with a date, which is derived from the latest date of any entry file in the database. I need to implement a little XQuery function to retrieve that date. We can't really do versioning beyond that, for (say) individual files, because any given entry will retrieve into itself entries from its constituent morphemes, and will link out in other ways to other entries.
• We need a subdomain for the project. However, moses.uvic.ca may not be acceptable for various reasons, and Nxaʔamxcín won't do as part of a domain name; we want ascii if possible. ECZH is considering the options.
• Entries for morphemes retrieved into the middle of an existing entry should be handled more intelligently. Right now, they simply embed themselves as if they were part of the parent entry. What I think we need is this:
  • When an entry is retrieved initially, a skeleton tabbed panel control is created, with a tab and panel for each of the constituent morphemes. The panel for each morpheme should have an @id attribute which is constructed from the combination of the parent and the child @xml:ids. All panels and their tabs should initially be display: none.
  • When a child entry is retrieved, it is placed into the appropriate panel, and its tab and panel are shown. Exactly how this works may be complicated, because it may involve showing the the whole tab control for the first time, or showing just the new panel, and flipping from an already-visible panel to the newly-populated one.
  • Panels should be (say) max-height: 8em; overflow-y: scroll, so that they don't take up more than a small part of the parent entry. They should be visually distinct from the main entry content.
  This will enable the reader to retrieve the full information about constituent morphemes if required, and switch between them, but without overwhelming the original entry.
• There's a range of documentation that needs to be completed in XML files peripheral to the main entry content, including documentation of terms, description of phonetic alphabet usage, and personography.