avoid nested xref

[pkra]

While jats and bits technically allow nested xref element, I think texml would do well to avoid it since it tends to lead to nested links in HTML which is invalid and causes usability issues.

Cases seen so far

• \tag{\ref{x}}\label{y} with \ref{y}.
• \renewcommand{\thelemma}{{\ref{x}}*} \begin{lemma} \label{y}... with \ref{y]
• nested cite, e.g.,\cite[(1.7), (1.8); \cite{X}]{Y}. (cf. also #183)
  • also ref nested in cite, e.g., \cite[eq. (3,\eqref{3.9}]{3}
• a label to an enumerate item inside a theorem environment causing a ref to look like <xref ...>(<xref ...>4.6</xref>.1)</xref> [this actually looks like a bug]
• nested hyperref \hyperref[xxx]{\hyperref[xxx]{xxxx}} [looks like a hack to get the right chapter+section numbers]

[pkra]

I added a more complete list from a quick search through publications. We have 94 cases across 11 publications right now, some of which seem like bugs.

Almost all cases are from links inside tag or cite.

[pkra]

As per F2F, we want to avoid nested xrefs in general.

183 will be one part of that. Some of the bug-like examples will need to be checked. Otherwise, we'll try to flatten the inner xrefs (here and downstream).

@davidmjones maybe an inner xref should be resolved to a generic wrapping element in case we want to do something downstream (e.g., style it). But we can wait until the need arises.

[pkra]

Just FYI (since I don't think texml should change here): downstream also runs into nested links with xref inside toc-entry. That's because we turn toc-entry to a so we have also flattened those xref (since the earliest days).

[pkra]

An observation for the texml side of things: I stumbled upon the old fact that texml might generate xref without rid attribute (but with a ref-key and undefined ref-type).

I think (but would like to check that) this happens only in extreme edge cases, i.e., I can only find 5 papers right now.

More precisely, it seems this happens only when the referenced labels no longer exists in the source, usually by some clean up.

• btran56: there's actually a bug here (stray content); this would nowadays be a ref-group, I think
• mcom3571: references to lines in an algorithm that's turned into svg
• mcom3577: link to a subfigure but the whole figure was turned into a single graphic (for no apparent reason)
• mcom3632: references to lines in an algorithm that's turned into svg
• mcom3651: another actual bug (stray content) and another case of (now) a ref-group

Since it only affects fairly old papers, I'm wondering if texml has made this obsolete.

Perhaps such an xref construction is an approach for the situation here, too.

[pkra]

@davidmjones ping on this.