Re: [Tools-discuss] [rfc-i] What do do about SVG

[Phillip Hallam-Baker <[e-mail]>]

On Thu, May 13, 2021 at 8:28 AM HANSEN, TONY L <[e-mail]> wrote:

> On 5/13/2021, 12:24 AM, "rfc-interest on behalf of Brian E Carpenter" <
> [e-mail] on behalf of
> [e-mail]> wrote:
>
>     After some investigation, I've understood that this particular problem
>     is because svgcheck doesn't allow <style> as a child of <svg>. Nor,
> after
>     some experiments, as a child of <path>, even though the RelaxNG in
>     RFC7996 appears to allow it. (Also, when <style> defines a color, and
>     I patch svgcheck/word_properties.py to allow <style>, svgcheck doesn't
>     seem to detect the color elements inside <style>.)
>
>     In the course of this I found another instance of a particular
>     bug in svgcheck (failure to increment errorCount).
>
>     So we have the facts that
>     (a) svgcheck is buggy;
>     (b) it doesn't implement the RelaxNG in RFC7996;
>     (c) sadly, we lost the maintainer of the code;
>     (d) our subset of TinySVG is very hard to generate with most drawing
> tools;
>     (e) experience shows that special SVG mangling programs are needed to
> prepare files for inclusion in RFCs;
>     (f) we've been told that TinySVG is no longer alive at W3C;
>     (g) browsers appear to be fully competent at interpreting full SVG.
>
>     How can we make progress on resolving this?
>
> As an FYI, I see three maintainers listed for svgcheck at
> https://pypi.org/project/svgcheck/. Can we poke them to address some of
> these issues, in particular a&b? Or provide them pull requests for the code?
>
> d,e,f are somewhat intractable unless we throw it out entirely and move to
> full SVG. g is one argument for that.
>
> However, there were several reasons behind going with a subset, laid out
> in section 2 of RFC 7996 and section 3.2 of RFC 6949. Any movement to
> support a larger version of SVG needs to address these requirements first.
>

I pointed out these issues over three years ago. This group has shown zero
interest in making any change. So no,  three more years of arguing over
which subset to pick is not an acceptable approach. I suggest:

1) Pick a deadline for making a decision. No more than six months.
2) Begin with the standard SVG and only eliminate what is absolutely
necessary to remove.
3) Make conformance with popular commercial drawing tools a requirement.
4) Consider the checker to be a support tool rather than an enforcement
mechanism. It is really not that difficult breaking out of the sandbox of
the current tools.

Alternatively, since W3C face the same need with respect to scripting in
documents as we do, perhaps we should just ask them what they do in this
regard. Dave Ragget's tiny was used to strip down HTML at one point, I bet
they have the same for SVG.

W3C has vastly more expertise in document formats than we do in IETF or
could ever hope to have. HTML and SVG were explicitly designed with
archival considerations in mind. Trillions of documents in these formats
exist. They are at this point just as established as ASCII or UNICODE as a
permanent infrastructure. If humanity loses the knowledge of how to
interpret HTML+SVG docs, it has probably forgotten how to interpret binary
data.

If people do want a custom approach, the way to go about it is to start
with the SVG DTD and remove elements. Checking an image is then merely a
matter of applying the modified DTD. RelaxNG has its place but that place
is not enforcing restrictions on a specification written in another schema
language.