Re: [rfc-i] getting SVG of RFC diagrams

[Carsten Bormann <[e-mail]>]

Hi Paul,

>> I put in a proof of concept at
> 
> This is a great proof of concept. It is very much like I was imagining.

Thank you.

> I'm not sure exactly how you are constructing the names of the parts. But the details of that can be bike shedded as needed.

File names should primarily come from the name= attributes of artwork/sourcecode.
However, few authors fill these in (and some get it wrong, e.g., in RFC 8688).
So, as a fallback, the code uses the slugifiedName= attribute created by the preptool (and, if that hasn’t be performed, it simulates the behavior of the preptool).

Multiple artwork/sourcecode with the same name= are aggregated (concatenated) under that name.
That would be mostly wrong with the guessed filenames from slugifiedName=, so here the extractor appends -b, -c… in case of a collision.
(Note that the slugifiedName= creation appends -2, -3…, so you might find a -2-b or so…)

> Question: are you actually extracting and storing all the pieces as a preprocessing step? Or is this virtual, where the pieces are extracted on demand?

In the PoC, this is done as preprocessing, essentially simply calling (an updated version of) kramdown-rfc-extract-sourcecode.

> If you are using a preprocessing step to extract the pieces, this could be made to work for docs prior to 8650 by using ad hoc techniques to extract the pieces from the .txt file. That could be done gradually on a demand basis. That would however require some sort of review process to ensure that is is done correctly.

I think that would be useful.
I’m not sure about how a review process would work, but people already are using aex and similar tools to extract ABNF, so by focusing on these higher-value targets we could cover 80 % of the needs with 20 % of the work.

(If the review process would be too arduous, we might need to fall back to a community effort.)

Grüße, Carsten