<Glazblog/>

Remember when I said the following?

any mechanism based on ID/IDREF introduces an extra keyword, the ID of the element ("mainauthor" here)... Asking a non-techie user to provide an ID is clearly suboptimal in terms of UX. That means the editing environment should pick one ID for the author, at the risk of using a human language not understood by the package's author or even a meaningless random ID.

Seems the situation is even worse than I expected... The EPUB3 Publications specification explicitly allows chains of subexpressions through ID/REF mechanisms and refines attributes. I guess it'll be clearer with this example:

<dc:identifier id="bookID">
  B64F547F-F2D1-4ACE-B8D2-D164785CDEB8
</dc:identifier>
<!-- meta element below refines the dc:identifier element above -->
<meta refines="#bookID"
      property="meta-auth"
      id="meta-authority1">My metadata Authority</meta>
<!-- link element below refines the meta element above... -->
<link refines="#meta-authority1"
      rel="xml-signature"
      href="../META-INF/signature.xml#Signature"/>

One ID/IDREF is already hard enough to deal with in UI but a chain?!? I can find one single word only to describe such a mechanism in a Standard oriented towards creation of visual products, i.e. oriented towards Wysiwyg-ness and nicely composed UIs: ridiculous. EPUB3 metadata are clearly a deep weakness in the EPUB3 format because of the incredible complexity they introduce in editing environments. Honestly, I am not sure to implement this, it would drastically uglify a UI that is already complex enough.