MJ came by today and we discussed the framework of the application, and made some preliminary decisions. This is my attempt to capture what ended up on the whiteboard.

The text side of the application (the TEI <text> element, in other words), will probably be handled as a DOM structure. It doesn't make much sense to try to model it in any other way, since it is directly editable (in that any element along with its children can be called up and altered by the user). We will need to keep an updated index of all the links between elements and <zone>s, though; each link would consist of a source element's @xml:id, the target zone's @xml:id, and the category of the link. It appears that categories will be applied, not to <div>s or <zone>s as before, but to links. This is necessary because the same <zone> may be linked from multiple elements for multiple purposes, and the same element may be linked to multiple <zone>s for multiple purposes.

In the interests of simplicity, I think it will make sense to write out the index of links into the TEI file directly. This can be done in categories, something like this:

<linkGrp type="myCategory">
  <link targets="#elementA #zoneB" />
  <link targets="#elementX #zoneY" />
</linkGrp>

I'm not sure yet where we should be storing the <linkGrp> elements; the header is the natural place, but none of its components seems to provide a good home for them.

These sets of elements can be rapidly read by the app when loading an existing file. However, for completeness, when saving, we should also supply the appropriate @facs and @corresp attributes on elements linking them to <zone>s, so that a processor not aware of the linkGrp system can still parse the relationships appropriately (although it would be unaware of the category information).

The index of all these relationships needs to be able to update itself in response to changes in the DOM, and it also needs to provide a brokering role enabling the GUI to display the right <zone> when an element is selected, or the right element when a <zone> is selected. In both cases, when it knows that there are multiple possible candidates, it should pop up a selection menu of some kind. It will also need to be able to display a list of every element which is a descendant of <text> and has an @xml:id, in the form of its <@xml:id> followed by some characters of its text content, so users can identify what they want to link to.

On the other side of the application, this is the basic model. (After our discussion, I did some more reading and realized we had been wrong about one Qt relationship, that between QGraphicsView and QGraphicsScene, so this description re-works that relationship.)

• At the top is HcmcFacsimile, a container for all the graphical constituents of the model. This maps to a TEI <facsimile> element.
• HcmcFacsimile contains a QVector<HcmcSurface>, which manages all the surfaces in the project.
• HcmcSurface maps to the TEI <surface> element. It descends from QGraphicsScene. It contains one HcmcPixmapItem, a descendant of QGraphicsPixmapItem; this corresponds to a TEI <graphic> element. HcmcSurface also contains a QVector<HcmcZone>. It needs its own unique @xml:id.
• Each HcmcZone corresponds to a TEI <zone> element, and descends from QGraphicsPolygonItem. This is the most challenging class to write, because it needs three states (invisible, view, and edit). It will also need a unique <@xml:id>, which the indexing broker will have to be aware of.
• HcmcSurface will render itself through a QGraphicsView, tied to a panel in a tabbed panel control.