Subject: Re: [Tools-discuss] [Cellar] expressing both svg graphics and ascii-art fallback within an rfc2xml version 3 file?

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Sep 2019 12:29:05 -0400

{reposting to tools-discuss}

Hello cellar,

The draft of FFV1 now uses xml2rfc version 3 as defined at
https://tools.ietf.org/html/rfc7991
<https://tools.ietf.org/html/rfc7991>. Presently in the markdown source of
the FFV1 draft, the math is maintained in both LaTeX expressions (which are
converted to SVG for inclusion in the RFC XML) as well as an Ascii Art
representation (heavily reliant on functions defined within the draft). For
example: 

vs

r_{i} = floor( ( R_{i} * S_{i,C_{i}} ) / 2^8 )

Whether in SVG or ascii art, this data is contained by the <artwork> node in
rfc2xml version 3. In https://tools.ietf.org/html/rfc7991#section-2.5
<https://tools.ietf.org/html/rfc7991#section-2.5> it states, 

   Alternatively, the "src" attribute allows referencing an external
   graphics file, such as a vector drawing in SVG or a bitmap graphic
   file, using a URI.  In this case, the textual content acts as a
   fallback for output representations that do not support graphics;
   thus, it ought to contain either (1) a "line art" variant of the
   graphics or (2) prose that describes the included image in sufficient
   detail.

A bit later it says that SVG data may be encoded and stored within the
<artwork>’s @src attribute such as  

   o  As a data: URI, such as: <artwork type="svg" src="data:image/
      svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3…">

So from this I was hoping we could work on one draft rfc2xml version 3 file
that could use the SVG image data or use the ascii art as a fallback; however
when I try to craft the <artwork> node with both such as: 

   <artwork type="svg" src="data:image/svg+xml,ENCODED_SVG_MATH_IMAGE_HERE”>FALLBACK_ASCII_ART_HERE</artwork>

then the output “v3-plaintext” output of the conversion tool at
https://xml2rfc.tools.ietf.org/experimental.html
<https://xml2rfc.tools.ietf.org/experimental.html>, does not use the textual
content of the <artwork> node as a fallback but instead places a warning such
as 

   (Artwork only available as svg: No external link available, see
   draft-ietf-cellar-ffv1-08.html for artwork.)

Is it feasible (recommended?) to have one rfc2xml XML document that could be
a source for both plaintext formats (using an ascii art fallback) and
non-plaintext formats such as HTML and PDF which would use the embedded SVG
data? 

Kind Regards,
Dave Rice

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Julian Reschke <[email-masked]>
Date: Sun, 1 Sep 2019 18:37:57 +0200

> non-plaintext formats such as HTML and PDF which would use the embedded SVG

<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.1>
might be what you're looking for.

Disclaimer: I proposed a much simpler solution, but that's where we are
right now.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 1 Sep 2019 18:46:17 +0200

Hi David,

Response at the bottom:

> non-plaintext formats such as HTML and PDF which would use the embedded SVG

Yes.  The specification of how to handle the text fallback in the RFC 799x
documents was in part contradictory, and also not as extensible and easily
editable as one could wish.  It currently looks like rfc7991bis largely will
follow the proposal discussed on the xml2rfc-dev list earlier this year, and
captured in the xml2rfc implementation notes draft here:

https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.1

which introduces an <artset> element which can contain multiple <artwork>
elements with different type attributes, for instance (artwork and some
details omitted:

  <artset>
    <artwork type="svg" src="..."/>
    <artwork type="ascii-art" ...>
	# ascii art
    </artwork>
  </artset>

For more on this, and for a light introduction to the v3 schema, check:
http://tools.ietf.org/src/xml2rfc/trunk/cli/doc/xml2rfc3.html#artwork-alternatives

Best regards,

	Henrik

> 
> Kind Regards,
> Dave Rice
> 
> 
> 
> 
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]
>

---

From: Dave Rice <[email-masked]>
Date: Sun, 1 Sep 2019 18:13:02 -0400

Hi Henrik, Julian,

> On Sep 1, 2019, at 12:46 PM, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi David,
> 
> Response at the bottom:
> 
> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.1 <https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.1>
> 
> http://tools.ietf.org/src/xml2rfc/trunk/cli/doc/xml2rfc3.html#artwork-alternatives <http://tools.ietf.org/src/xml2rfc/trunk/cli/doc/xml2rfc3.html#artwork-alternatives>

Thanks, this was exactly the clarification that I needed! I see that with the <artset> use described here, that the v3-plaintext and v3-html outputs of https://xml2rfc.tools.ietf.org/experimental.html <https://xml2rfc.tools.ietf.org/experimental.html> use the appropriate <artwork> for the output. If you’re interested, my work to ‘build’ this XML from out markdown source is in https://github.com/FFmpeg/FFV1/pull/160 <https://github.com/FFmpeg/FFV1/pull/160>, and an example of <artset> in the output of this PR can be seen at https://gist.github.com/dericed/3063446119a6e5971ecad29027977073#file-draft-ietf-cellar-ffv1-08-xml-L489-L502 <https://gist.github.com/dericed/3063446119a6e5971ecad29027977073#file-draft-ietf-cellar-ffv1-08-xml-L489-L502>.

Thanks so much,
Dave Rice