New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
reschke opened this Issue Nov 15, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@reschke

reschke commented Nov 15, 2017

<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.

@reschke reschke changed the title from \<relref> is not needed, move functionality into \<xref> to <relref> is not needed, move functionality into \<xref> Nov 15, 2017

@reschke reschke changed the title from <relref> is not needed, move functionality into \<xref> to <relref> is not needed, move functionality into <xref> Nov 15, 2017

@levkowetz

This comment has been minimized.

Show comment
Hide comment
@levkowetz

levkowetz Nov 16, 2017

Collaborator

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.

Collaborator

levkowetz commented Nov 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ronaldtse

ronaldtse Dec 8, 2017

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

ronaldtse commented Dec 8, 2017

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

@opoudjis

This comment has been minimized.

Show comment
Hide comment
@opoudjis

opoudjis Dec 10, 2017

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.

opoudjis commented Dec 10, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment