- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 29 Apr 2019 20:40:18 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `SVG native — XML entities / CDATA`, and agreed to the following: * `RESOLVED: A valid SVG Native document must not contain any of the external or internal XML DTD subset.` <details><summary>The full IRC log of that discussion</summary> <AmeliaBR> Topic: SVG native — XML entities / CDATA<br> <AmeliaBR> GitHub: https://github.com/w3c/svgwg/issues/672<br> <AmeliaBR> Chris: I think we should make these parts of XML not required in a rendering agent. That would avoid a lot of possible issues. But at the same time, a full XML parser could be used.<br> <AmeliaBR> Myles: Explain.<br> <AmeliaBR> Chris: We'd disallow these aspects in a SVG Native document. So you'd get the same results whether the rendering agent supports them or not.<br> <AmeliaBR> Myles: Would the software need a two-step parsing?<br> <AmeliaBR> Chris: No, XML parsing and validation are separate steps. So the regular XML parser could be used, but if this extra content is there, it would be invalid.<br> <AmeliaBR> Myles: But what should the software do if it finds a DTD fragment or other feature that isn't supported.<br> <AmeliaBR> Chris: We haven't really defined that yet. But it wouldn't be an SVG Native document any more.<br> <AmeliaBR> Myles: Ok. So it seems we agree that we should exclude these features. But I think we need to define what happens when they are there.<br> <AmeliaBR> Chris: But we also have to decide that for other features, like SMIL features or text.<br> <AmeliaBR> ... We could have separate validators that confirm whether a document is valid SVG Native, but the software wouldn't need to validate prior to rendering.<br> <AmeliaBR> ... I know other file types do that, eg. fonts. But a badly made font can crash the whole OS.<br> <AmeliaBR> Myles: So, at what stage would the document be enforced? Would software exporters have to warn if these features are present?<br> <AmeliaBR> Chris: For software tools, they usually have multiple export paths with different features enabled or not.<br> <AmeliaBR> Dirk: I agree. Software tools no what to export when. How they create that doesn't really matter, so long as the document at the end of the process is valid SVG Native.<br> <AmeliaBR> ... We can create independent validators that aren't tied to any particular software (implementation or authoring tool).<br> <AmeliaBR> Sairus: I think this is reasonable. But at the same time, e.g., fonts do show up with SVG that is outside or subset. So we still need rules on what to do.<br> <AmeliaBR> Myles: In a classic design, a parser turns a document to a DOM, and then renderer can use that DOM & decide which features are rendered. But if the parser includes an unsupported feature, the DOM tree could be wildly different. At the rendering level, it doesn't know how that was created.<br> <AmeliaBR> Dirk: I think that's why we should focus the restriction on what is a valid SVG Native document & not say what the renderer should do.<br> <AmeliaBR> Sairus: But the idea of a subset is that the missing features are easily skippable. It doesn't sound like an XML entity is easily skippable.<br> <AmeliaBR> ... if they act like a macro and substantially alter the document, they should be forbidden.<br> <AmeliaBR> Amelia: I think we agree that XML entities shouldn't be part of a valid SVG Native document. The question is whether an SVG Native renderer needs to enforce validity.<br> <AmeliaBR> Dirk: Can we make a resolution of that part that we do agree on?<br> <AmeliaBR> Amelia: What's the full set of XML features we're disallowing?<br> <AmeliaBR> Chris: Both external and internal DTD subset are disallowed.<br> <AmeliaBR> RESOLVED: A valid SVG Native document must not contain any of the external or internal XML DTD subset.<br> <AmeliaBR> Amelia: Next question: what does this mean from the software side?<br> <AmeliaBR> Myles: Three options I see: (1) renderer must support the features (2) renderer must ignore (3) undefined. Not sure what is best.<br> <AmeliaBR> Chris: I think I prefer the third. If you use a full XML parser, you get what you get. If not, it will be different. For valid content, there won't be a difference. For invalid content, there may be a difference.<br> <AmeliaBR> Myles: There are currently at least three different implementations that a close to what we'd call an SVG Native renderer. Have we looked at what they do?<br> <AmeliaBR> Sairus: I don't think so. But given we're working with existing implementations, that leans towards being open.<br> <AmeliaBR> Myles: Can we resolve pending further research?<br> <AmeliaBR> Chris: I'd rather do the research first.<br> <AmeliaBR> Amelia: To clarify, when we talk option 3, do we really mean undefined, or do we mean two possible choices: match full XML, or fully ignore. Can't just do things partly.<br> <AmeliaBR> Myles: I think that's assumed.<br> <AmeliaBR> Sairus: I would like to get this resolved sooner. We've got new teams looking at SVG OpenType support, e.g., the FreeType group.<br> <AmeliaBR> Myles: That's important & if possible it would be great to get them on a call to find out their constraints.<br> <AmeliaBR> Sairus: Sure. Follow up with me & copy Dirk, since I think they want to build on the renderer he released last week.<br> <AmeliaBR> Chris: BTW, hooray for Dirk's new SVG Native renderer!<br> <AmeliaBR> Myles: Can we make a tentative resolution?<br> <AmeliaBR> Dirk: Let's wait.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/672#issuecomment-487735448 using your GitHub account
Received on Monday, 29 April 2019 20:40:20 UTC