[rfc-i] [xml2rfc] use of sourcecode type
cabo at tzi.org
Wed Jul 22 21:35:53 PDT 2020
> On 2020-07-23, at 06:22, John R Levine <johnl at taugh.com> wrote:
> On Thu, 23 Jul 2020, Carsten Bormann wrote:
>> On 2020-07-23, at 05:40, John R Levine <johnl at taugh.com> wrote:
>>> o svg
>> In an authoring system such as kramdown-rfc, you get to use source-code (e.g., some form of UML) to generate artwork (right now limited to our SVG subset, or plaintext (“ASCII”) art).
>> The existing vocabulary cannot represent this.
>> But that is maybe mostly OK, because at the author-publisher interface, the source code (i.e., editable form) is no longer needed.
>> Until it is.
> This list of artwork types isn't cast in stone. If we need new ones, we can add them.
If we want to add the artwork source code to the artwork types, we need to identify them as “needing processing” — presenting them as plaintext (“ASCII”) art may make more or less sense, but they really aren’t.
So we have
Plaintext art x x
SVG - (*) x
Source code ? (**) p
Where x means “can be presented in” and p means “needs processing for”.
(With tools such as ditaa and goat, the difference between source code and plaintext art diminished.) (**) Some tools are able to generate fallback TXT, notably plantuml for some of its input forms. (*) This is the place where artset was intended to help. We may see all three, source code, fallback plaintext, and SVG in an artset...
More information about the rfc-interest