[rfc-i] extensions for <artwork> and friends
Joe Hildebrand (jhildebr)
jhildebr at cisco.com
Mon Feb 22 09:44:42 PST 2016
Is https://github.com/reschke/xml2rfc the best place to get your XSLT?
On 2/18/16, 5:25 AM, "rfc-interest on behalf of Julian Reschke" <rfc-interest-bounces at rfc-editor.org on behalf of julian.reschke at gmx.de> wrote:
>1) Ability to highlight a part of artwork.
The particular example you give I find very difficult to tell what exactly is bolded and why. I worry that would often be the case for this feature.
>2) Ability to make part of artwork the target of a link.
>Documentation: none currently, essentially done by allowing a <span>
>element inside <artwork>, and allowing that <span> element to carry an
You could achieve this by breaking up the file into multiple <sourcecode> chunks. If there was no intervening text, it might look just fine, but might need us to tweak the CSS a little.
>3) Ability to style part of artwork for syntax highlighting.
I'd really like this one day, particularly assuming the RSE allows us to use color. But it should be for <sourcecode> only.
>4) Ability to have index entries for things occurring in artwork.
>Example: entries in
>5) Ability to include <xref>s in artwork.
I'm more sympathetic to this in <sourcecode> than <artwork>.
>6) Ability to hyperlink within ABNF (and similar types of artwork).
Same here. In <sourcecode>, maybe. Perhaps in a <verbatim> tag if we end up with one.
>a) Does this interfere with automatic extraction of source code?
>No, it does not. The artwork extractor just needs to stick to the text
>content of the element. (Implementation:
I'd want to test it with CDATA, and I'm worried about extra spaces being inserted. XML formatting should already be turned off in <sourcecode> and <artwork>, so hopefully that won't cause an issue.
>b) Does this interfere with automatic syntax highlighting through JS (in
>case we want do do that)?
>Not necessarily; for instance, <https://github.com/google/code-prettify>
>deals with this properly.
I think that's likely an output formatter transformation, so it's even less likely to be an issue.
More information about the rfc-interest