[rfc-i] Preparing for allowing v3 submissions into the repository (was Re: [xml2rfc-dev] Alternate artwork vocabulary and post preptool)

Julian Reschke julian.reschke at gmx.de
Thu Feb 7 21:22:24 PST 2019


On 08.02.2019 00:03, Martin Thomson wrote:
> Hi Robert,
> 
> What is the status of inline SVG?
> 
> For the purposes of authoring, a separate file is great.  The preptool might inline the file to ensure that there is just one file to manage.
> 
> A data: URI is the worst possible option from a usability perspective.  It's also less efficient.
> ...

<https://greenbytes.de/tech/webdav/rfc7998.html#rfc.section.5.5.1>:

> If an <artwork> element has type='svg' and there is an "src" attribute, the data needs to be moved into the content of the <artwork> element.
> 
>     If the "src" URI scheme is "data:", fill the content of the <artwork> element with that data and remove the "src" attribute.
>     If the "src" URI scheme is "file:", "http:", or "https:", fill the content of the <artwork> element with the resolved XML from the URI in the "src" attribute. If there is no "originalSrc" attribute, add an "originalSrc" attribute with the value of the URI and remove the "src" attribute.
>     If the <artwork> element has an "alt" attribute, and the SVG does not have a <desc> element, add the <desc> element with the contents of the "alt" attribute.

So yes, per spec, the content would be in-lined as-is, not moved into a 
"data URI".

(there are some issue with the text above because it doesn't really talk 
about relative references which would be most common, but the intent is 
pretty clear)

Best regards, Julian


More information about the rfc-interest mailing list