<relref> is not needed, move functionality into <xref>

[reschke]

<relref> provides functionality that rfc2629.xslt has supposed through extensions to <xref> for a long long time: https://www.greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref

As a matter of fact, this functionality started as extension to <xref> in the drafts leading to RFC 7991, and were moved to a new element for reasons I still do not get (see https://tools.ietf.org/rfcdiff?url2=draft-hoffman-xml2rfc-18.txt).

In the meantime, I've added experimental support for <relref> to rfcc2629.xslt, with the goal to understand how it actually differs from the extensions defined for <xref> earlier on. <See https://github.com/reschke/xml2rfc/blob/master/rfc2629.xslt>. The answer is: it really doesn't, except that things get slightly more messy because we have now two elements with very similar functionality.

From an authoring point of view, it doesn't make any sense to have to switch to a different element when making a citation more specific by adding the version number.

I thus propose to instead go back to what was defined in draft-hoffman-xml2rfc-18, and add the missing bits about the preptool there.

[levkowetz]

I support this. When I first read about , I was baffled, and it was really hard to understand what it was there for -- I kept thinking "but this is what does", and had to go back and forth between the descriptions in order to ferret out the difference. Quite confusing. Enhancements to will be much easier to grasp.

[ronaldtse]

Agree that enhancements to <xref> is much better than two separate elements with highly duplicative intent.

[opoudjis]

I'll add that in integrating BibXML to Asciidoctor for our preprocessing, having two different XML tags for the BibXML CSL library has proven prohibitive.

[stpeter]

Because it seems that we've already made this change, I'm going to close this issue and point issues specifically related to relref at this issue.

[jrlevine]

Updated draft