Subject: [xml2rfc] xml2rfc v2 <artwork src="...">

From: Sean Leonard <[email-masked]>
Date: Thu, 8 Sep 2016 23:58:17 -0700

Hello:

xml2rfc v2 says that <artwork> can have a @src attribute, which is a URI. I assume that the base URI is the current URI of the xml2rfc document.

What is the proper behavior when an <artwork> has textual data and also has the src attribute? Is it a fatal processing error, or does one take precedence? RFC 7749 does not say.

Note: The xml2rfc v3 draft says: “It is an error to have both a "src" attribute and content in the <artwork> (or <sourcecode>) element.” Therefore I would say that v3 treats the condition as fatal. The xml2rfc v3 preptool draft suggests that @src is supposed to be factored out during the posting/publication process, by including the contents directly in the inner XML element, or by using a data: URI.

It appears that the xml2rfc v2 2.5.1 (Python) completely ignores the src attribute on <artwork>, as confirmed with both testing and source code analysis. It does not even care, so <artwork src=“foo.txt"/> is treated as <artwork></artwork>, and the presence of both text and @src results in just the text being used. I just tried submitting an Internet-Draft with an <artwork> with both @src and text, and the upload tool took it (I didn’t actually post the draft).

Would this be loosely classified as a “bug” (or missing feature), or is this by design?

Sean

PS I am trying to decide if a tool should basically ignore <artwork> @src, error out, or do something else.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 9 Sep 2016 09:27:34 +0200

> xml2rfc v2 says that <artwork> can have a @src attribute, which is a URI. I assume that the base URI is the current URI of the xml2rfc document.

Yes.

> What is the proper behavior when an <artwork> has textual data and also has the src attribute? Is it a fatal processing error, or does one take precedence? RFC 7749 does not say.

It depends.

rfc2629.xslt uses the @src attribute when producing HTML.

xml2rfc.tcl AFAIR uses the textual content when producing plain text and 
the @src attribute when producing HTML.

That is, the text content is used as a fallback when the output format 
doesn't support graphics.

(Note that the behavior might depend on the presence of 
<https://greenbytes.de/tech/webdav/rfc7749.html#element.artwork.attribute.type>, 
and it starting with "image/" -- I don't believe anybody has tested this 
with any other media type).

> Note: The xml2rfc v3 draft says: “It is an error to have both a "src" attribute and content in the <artwork> (or <sourcecode>) element.” Therefore I would say that v3 treats the condition as fatal.…

That's IMHO a bug in the v3 draft.

> Would this be loosely classified as a “bug” (or missing feature), or is this by design?

I'd consider this a bug with low prio, as it doesn't affect the output 
formats the IETF *currently* works on.

> PS I am trying to decide if a tool should basically ignore <artwork> @src, error out, or do something else.

It depends on the audience of that tool, I'd say.

Best regards, Julian

---

From: Sean Leonard <[email-masked]>
Date: Fri, 9 Sep 2016 01:04:16 -0700

On 9/9/2016 12:27 AM, Julian Reschke wrote:
>> xml2rfc v2 says that <artwork> can have a @src attribute, which is a 
>> URI. I assume that the base URI is the current URI of the xml2rfc 
>> document.
>
> Yes.
>
>> What is the proper behavior when an <artwork> has textual data and 
>> also has the src attribute? Is it a fatal processing error, or does 
>> one take precedence? RFC 7749 does not say.
>
> It depends.
>
> xml2rfc.tcl AFAIR uses the textual content when producing plain text 
> and the @src attribute when producing HTML.
>
> and it starting with "image/" -- I don't believe anybody has tested 
> this with any other media type).

Okay, thanks. Overall it sounds like the intent of @src in v2 is to be 
used for (binary) graphics formats, with the text content being a 
fallback to the (binary) graphic.

>
>> Note: The xml2rfc v3 draft says: “It is an error to have both a "src" 
>> attribute and content in the <artwork> (or <sourcecode>) element.” 
>> Therefore I would say that v3 treats the condition as fatal. The 
>> xml2rfc v3 preptool draft suggests that @src is supposed to be 
>> factored out during the posting/publication process, by including the 
>> contents directly in the inner XML element, or by using a data: URI.
>

Well, if it's a bug, it's a deliberately-engineered bug: the text in 
draft-iab-rfcv3-preptool-02 says repeatedly to error out if both @src 
and text content are present...

>
>> It appears that the xml2rfc v2 2.5.1 (Python) completely ignores the 
>> src attribute on <artwork>, as confirmed with both testing and source 
>> code analysis. It does not even care, so <artwork src=“foo.txt"/> is 
>> treated as <artwork></artwork>, and the presence of both text and 
>> @src results in just the text being used. I just tried submitting an 
>> Internet-Draft with an <artwork> with both @src and text, and the 
>> upload tool took it (I didn’t actually post the draft).
>>

Ok, good enough for my purposes for now.

Sean

---

From: Julian Reschke <[email-masked]>
Date: Fri, 9 Sep 2016 10:09:25 +0200

On 2016-09-09 10:04, Sean Leonard wrote:
> ...

Indeed.

> ...
> ...

Yes, I happen to disagree with multiple things in v3.

> ...

Best regards, Julian