Subject: [xml2rfc] HTML V3 vs RFC Markup

From: Anders Rundgren <[email-masked]>
Date: Wed, 2 Oct 2019 10:00:15 +0200

Hi,
The new HTML format is awesome!

I do though have some issues with maintaining a good RFC Markup document and an HTML variant using the same XML V3 as input.

<tt> gives "text" in RFC Markup.  That MAY fit some RFCs but not all.
<em> gives *text* in RFC Markup. That MAY fit a few RFCs.

I think you should add an optional modifier.

Another issue related to document format specific renderings is <artwork>.

In RFC Markup you are limited to "line art" but in HTML you can use SVG but they would (in most cases) represent the same information.
An optional attribute "render" could make this slightly more elegant.

Maybe an optional render attribute could be the generic fix?

Anders

---

From: Julian Reschke <[email-masked]>
Date: Wed, 2 Oct 2019 11:12:07 +0200

On 02.10.2019 10:00, Anders Rundgren wrote:
> I do though have some issues with maintaining a good RFC Markup document
> and an HTML variant using the same XML V3 as input.
>
> In RFC Markup you are limited to "line art" but in HTML you can use SVG
> but they would (in most cases) represent the same information.
> ...

What would that attribute do?

Best regards, Julian

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 2 Oct 2019 13:37:21 +0200

> What would that attribute do?

<artwork render="format.html" type="svg"><svg ...>...</svg></artwork>

would only return data to the print process when the HTML format is requested
while

<tt render="format.rfcmarkup">...</tt>

would maybe only disable <tt> for RFC Markup since it is an attribute to text.

<t render="format.form.rfcmarkup"> would presumably work analogous to <artwork>

The "render" attribute would hold a list of known output formats to which it applies.

Anders

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 2 Oct 2019 14:07:41 +0200

Hi Anders,

> I think you should add an optional modifier.

No, it should be consistent across documents.  I'd love a better option
for <tt> myself, but I don't have one.

> In RFC Markup you are limited to "line art" but in HTML you can use
> SVG but they would (in most cases) represent the same information.

> Maybe an optional render attribute could be the generic fix?

Please start by reading this, and see if it resolves things for you:

http://durif.tools.ietf.org/src/xml2rfc/trunk/cli/doc/xml2rfc3.html#artwork-alternatives

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 2 Oct 2019 14:05:14 +0200

> would only return data to the print process when the HTML format is

Still not getting it.

The current approach (see
<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.1>)
allows both cases (no textual fallback, or textual fallback). What's
missing?

Best regards, Julian

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 2 Oct 2019 15:30:45 +0200

> allows both cases (no textual fallback, or textual fallback). What's

Thanx  Julian,
I haven't studied this document before.

I indeed managed to switch between ascii-art and svg.
With the latter I noted a small (but difficult) problem though: Sizing/Scaling is not entirely logical.
I would assume that most authors would like SVGs to keep a relation to document font size and getting a scrollbar (like they get for ascii-art) when the SVG doesn't fit.
I would consider some kind of sizing attribute.  Using a viewBox SVGs fills the window horizontally which is fine in some cases but.

Regarding <em> and <tt> the implementation notes contains a line:
*  <tt>: Guidance requested.  Now rendered as "text"

Regards,
Anders