Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
<relref> is not needed, move functionality into <xref> #26
<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.
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.