fix: Allow any SVG - #1335
Conversation
Based on RFC 9896, the SVG that can be included in an RFC is a matter of judgment, not something that can be validated by a tool. Implement that. I searched for a schema that can be used with this, but it turns out that SVG doesn't subscribe to that philosophy any more: > Because SVG is extensible, conformant "image/svg+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document. -- [Section J.2 of https://www.w3.org/TR/SVG/](https://www.w3.org/TR/SVG2/mimereg.html#mime-registration) Therefore, this adds a very simple wildcard rule to the schema, which will allow virtually anything. I've tested this with the latest aasvg and it's fine. Note: There is a RelaxNG schema for SVG floating around. It's broken. Note(2): v3.rnc contains trailing whitespace, which is bad mojo. I left it there, but you should consider trimming it out. Note(3): There is an awful lot of duplication of code for these schema. I left that alone too, copying the change to all the necessary places. Still, that seems like something that could be improved.
|
I worked out something for the documentation. That was quite unpleasant. |
|
@martinthomson, thanks for your work on this, but this PR can't be merged because it allows for executable scripts. The RPC will be consulting with the community before IETF 127 to create updated SVG guidance, and this guidance will be checked by new code. I have created an issue in the RFCXML repo to track this SVG update: ietf-tools/RFCXML#48 |
|
I spoke with @rjsparks about this offline and suggested that basic sanitization might work. I've just implemented a lightweight sanitization for SVG in this branch. Robert mentioned a desire to use something like nh3, but if you want to do that, then I suggest that someone else take this work on. (I have no interest in following an ever-increasing piece of string.) |
Based on RFC 9896, the SVG that can be included in an RFC is a matter of judgment, not something that can be validated by a tool. Implement that.
I searched for a schema that can be used with this (see notes), but it turns out that SVG doesn't subscribe to that philosophy any more:
Therefore, this adds a very simple wildcard rule to the schema, which will allow virtually anything. I've tested this with the latest aasvg and it's fine.
Note(1): There is a RelaxNG schema for SVG floating around. It's broken; I tried it and gave up.
Note(2): Several of these files contain trailing whitespace, which is bad mojo. I left it there, but you should consider trimming it out.
Note(3): There is an awful lot of duplication of code in schema files. I left that alone too, copying the change to all the necessary places. Still, that seems like something that could be improved.
Note(4): I'm not very happy with my understanding of the testing infrastructure. I added a test that the
<style>element was passed through in the test files, but I don't think that is really testing anything at all. I wanted to add a test XML file totests/inputand have that tested, but nothing I tried worked for that and it doesn't look like it would end up testing anything relevant anyway.Note(5): On that testing infrastructure piece, I edited source files for what looks to be used to generate
./tests/valid/manpage.txt(and./tests/valid/docfile.htmlas well), but I couldn't see how to have it generate a replacement file. It doesn't look like it is being generated from its source files.Note(6):
./xml2rfc/data/rfc7991.rngcomments out the SVG parts, so I left those alone. After all, these are just schema for that RFC, which is defunct now, so maybe it's historical (?). And of course, this is more schema duplication!