This is my plan, along with XUpdate code, for transforming the wealth of different reference types we have into a more consistent scheme.

• First, we need to alter the db structure again. Because we want the consistency of encoding all references with relative paths, and we want to be able to use the same structure in any document, we need to rework the db structure itself, from this:

  ----mariage
      ----anthology
          ----images
          ----original_texts
      ----articles
      ----biblio
      ----intros
      ----references
  

  to this:

  ----mariage
      ----anthology
          ----images
          ----original_texts
      ----editorial
          ----articles
          ----intros
      ----back_matter
          ----references
          ----biblio
  

  This places all actual content documents at the same level of the hierarchy, so referencing can always go up two levels and then down two. Links from one ref tag to another inside the same document can maintain the same structure. This makes for consistency (ease for markup folks) and robustness (if files are split or merged at the bottom level, references will still work; just the filename will need to be changed).
• A standard reference popup needs to be converted from this:

  <ref type="reference" target="references.xml#etna">Mont Etna</ref>

  to this:

  <ref target="../../back_matter/references/references.xml#etna">Mont Etna</ref>

  This can be done using the following xupdate code:

  declare default element namespace "http://www.tei-c.org/ns/1.0";
  
  for $r in collection('/db/mariage')//TEI[@xml:id='varin']//ref[@type="reference"]
  let $newRef := <ref target="../../back_matter/references/{$r/@target}">{$r/(*|text())}</ref>
  return <done>
  {update replace $r with $newRef}
  </done>
  

  The corresponding XSLT code also needs to be changed in teiLinking.xsl, from this:

  <xsl:template match="//text//ref[@type='reference']">

  to this:

  <xsl:template match="//text//ref[contains(@target, '/references/')]">

• An external link (<ref target="http://...">) needs no change at all, either to XML or XSLT.
• A bibliographical reference needs to be changed from this:

  <bibl corresp="../biblio/biblio.xml#dejean_2003">

  to this:

  <ref target="../../back_matter/biblio/biblio.xml#dejean_2003">

  These have not yet really been handled in XSLT properly, but the basic rule would be that XQuery would go about retrieving all items from the biblio.xml file and putting them into the back tag of the article XML, alongside any locally-defined biblio items, and they would then be rendered out to the page at the bottom of the article (and made available as popups too). I've already made this change in the only article so far marked up (and not yet finished), and in the toc intro that's also making use of it.
• Multi-targetted round-trip references such as those in the early documents will have to be changed from this:

  <ref xml:id="wifes_lover" target="amant.xml#wifes_lover a_une_femme_mariee.xml#wifes_lover">

  to this:

  <ref xml:id="wifes_lover" target="../../anthology/images/amant.xml#wifes_lover ../../anthology/original_texts/a_une_femme_mariee.xml#wifes_lover">
  

  The @xml:id attribute will obviously have to be preserved here. One wrinkle here is that the components of the target element do not currently specify the subcollection in which the target document is to be found. There are actually only 11 of these items, so they might as well be changed manually. XSLT code which renders them into links will also have to be changed, but see below; this case can be conflated with the next.
• In articles, what I was doing provisionally like this:

  <ref target="xhtml.xq?id=grande_destruction">

  will now be done like this:

  <ref target="../../anthology/grande_destruction.xml">

  These items can now be handled exactly the same way as the items above: first of all, check whether they link has multiple targets; if not, then render a simple link to the XHTML view of the document; if so, create whatever output structure is most elegant for creating multiple links; in both cases, write the @xml:id attribute out as an @id attribute in the XHTML in case incoming links target it.

I think this is a complete plan, and it's basically ready to go; it'll take a day or two to implement it properly, and during that time I need to make sure that no-one is editing existing documents. Next week would be a good -- no-one from the project will be working.