Re: [rfc-i] No, constraining to a custom SVG profile is not trivial

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

On Tue, Jan 21, 2020 at 10:31 PM Brian E Carpenter <
[e-mail]> wrote:

> On 22-Jan-20 06:03, Michael Richardson wrote:
> >
> > Phillip Hallam-Baker <[e-mail]> wrote:
> >     > But the other point I will make is that 2014 is six years ago and
> the
> >     > statement made then was that these issues could be reopened at a
> later
> >     > date. I am simply holding the group to the promise made then that
> >     > these issues can be revisited.
> >
> > I would support revisiting the question of a SVG profile... in 2021.
> > Certainly by IETF110, with planning for that discussion at IETF109.
> > So... after we have a new permanent RFC-editor.
> >
> > I think that the change to v3-XML under changing leadership is difficult
> > enough as it is.
> >
> > In the meantime, in the I-D series, I think that we should tolerate a
> variety
> > of SVG inputs, and we should encourage monochrome inputs, but not require
> > them.
>
> Until idnits does detailed SVG checking, that shouldn't be an issue. But
> what's the use when RFCs are constrained to black&white?
>
> I agree that the lack of coloured shading is annoying for many people, but
> *using* shading is annoying for people with limited colour vision.
>
> I have an example that Michael will recognise (see attached). The second
> version passes svgcheck, having been run through my fix-up code. This is
> what we lose by sticking to the current spec.
>
> But the fact is that what we can do under the current spec is
> intentionally very limited. I understand Phill's annoyance but as you say,
> there is a lot of work & time involved in changing the spec.
>

There was sufficient ID-Nits checking to prevent me submitting the drafts
without making changes. Otherwise, I would have submitted them.

Given that IDs expire in six months... I think we should decouple the ID
and RFC requirements.

Looking forward, we need a different approach. Instead of defining a
profile we should specify a set of restrictions. That might not sound like
a major change but for me as an implementer it is huge.

Implementing SVG-minus means:

1) Parse the XML tree, incorporated CSS elements and resolve all links
2) Replace class and style attributes with the corresponding attributes
3) Remove all colors and fonts that are not supported.
4) Map unsupported characters to ?
5) Rename id elements to ensure uniqueness when included in the final
document.

Implementing the first three took me about eight hours to produce an
(almost) fully engineered tool to the above spec that runs on Windows, OSX
and Linux. I don't have a full CSS implementation but it is sufficient to
pares the CSS generated by all the drawing tools I have seen. It does not
currently rename the ID elements, it just deletes them all. That is ok for
SVG tiny but would not work for full SVG (as markers use XLink). It does
map Unicode characters but I still don't have an authoritative set of
permitted code points.

The parse tool I am using is capable of XML schema validation and
performing schema driven binding to strongly typed backing classes. But I
am only using the raw parse tree. So the tool will probably work without
modification on XML/2.0

This is a much simpler approach than the current spec. It is also easier to
implement, test and use. Trying to decipher a profile written in Relax-NG
using the documentation in the base spec written in XML-Schema would be
awful even if the IDNits tool and the Relax schema were consistent but they
aren't.