search

rfc-format / draft-iab-xml2rfc-v3-bis

-bis document for the RFC format xml2rfc v3 draft
6 stars 10 forks source link

<artwork> types #206

Open jrlevine opened 2 years ago

jrlevine commented 2 years ago

RFC 7991 says the preferred types for \ are ascii-art, binary-art, call-flow, hex-dump, and svg, with the list to be updated. It is unclear what the type is supposed to mean. The ascii-art, binary-art, and svg types describe a format, the others are the meaning of the contents. In RFCs published to date, there are many ascii-art and svg, two RFCs with hex-dump, one each with call-flow, cddl, CBORdiag, and yangtree, and one with "message/http; msgtype=\"response\"" There is no binary-art but the xml2rfc code treats the src argument as a file to be imported and displayed as an HTML IMG element.

Proposal: deprecate everything except ascii-art, svg, and maybe binary-art. If people want to put semantic tags on the material, it's \

reschke commented 2 years ago
  1. "svg" is entirely useless for inlined SVG, as the processor can automatically detect it
  2. It would make the type attribute entirely optional; in your list above the case of an example, such as for a URI, is notably missing.
jrlevine commented 2 years ago

The type attribute is optional now. The vast majority of artwork has an empty type which defaults to ascii-art. You can always tell by inspection whether an element is svg, whether it's inline or external, but I don't see any harm in stating the intention.