[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.
>Example: <http://greenbytes.de/tech/webdav/rfc5987.html#rfc.section.4.2> 
>(here: bold)

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.
><http://greenbytes.de/tech/webdav/rfc7749.html#grammar.address>, linked 
>from <http://greenbytes.de/tech/webdav/rfc7749.html#rfc.section.2.2.p.3>
>Documentation: none currently, essentially done by allowing a <span> 
>element inside <artwork>, and allowing that <span> element to carry an 
>anchor attribute.

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.
>Example: <http://greenbytes.de/tech/webdav/rfc7749.html#schema>

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 

See 2.

>5) Ability to include <xref>s in artwork.
>Example: <http://greenbytes.de/tech/webdav/rfc7230.html#uri>

I'm more sympathetic to this in <sourcecode> than <artwork>.

>6) Ability to hyperlink within ABNF (and similar types of artwork).
>Example: <http://greenbytes.de/tech/webdav/rfc7230.html#http.uri>

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.

Joe Hildebrand

More information about the rfc-interest mailing list