[svg-integration] Validation of focus

Hi,

I looked at the SVG Integration spec. I agree that we should have a section in SVG 2 or separate module or even a separate spec that describes how other markup languages interact with SVG.


A) I think the SVG Integration spec tries to do more that the abstract says or would be required by any spec referencing SVG Integration. In particular:

1) SVG Elements, Attributes, and Properties
If an implementer is interested in supporting SVG, he can look up the individual specification. There is no need for a summary of all SVG levels. I agree that it might be interesting and it could be a primer to SVG or in the appendix for reference, but I do not think that it belongs in the integration spec. The knowledge of the supported elements does not influence the interaction of SVG with other markup languages.

2) Foreign Content in SVG
The spec is about integrating SVG into other languages. Anything else should and is defined in SVG directly. There is no need for this section in the integration spec.

3) Extending SVG
This is kind of an hybrid. I can understand that this could be part of SVG Integration, but on the other hand it isn't. Reading section "Extension conformance requirements" I wonder what the intention of this section actually is. If someone wants to extend SVG and it is not conferment to SVG Integration, he just does not support the SVG Integration spec. This section tries to restrict extensions while it does not have the authority to do that. If we want to define extensibility to SVG, it must be in the SVG specification. Even then I would not restrict extensibility since there could always be good reasons to violate the restriction.

4) Foreign namespaces and private data
The usage of foreign namespaces is actually defined by XML and does not need to be specified here. In contrary, the integration spec may allow not to support foreign namespaces depending on the context (inline SVG in HTML5).

5) XML encoding conformance requirements
This section should just say that the SVG specification defines encoding requirements. No need to go into details. It should be more of a prior for the next section….

6) Non-XML encoding conformance requirements
This section basically requires that every language that includes SVG must support all XML requirements. This is not possible with inline SVG in HTML. This section should rather say that a language that integrates SVG can restrict XML abilities inherited by SVG or replace them. An XML roundtrip is not possible and should not be required.


B) Focus of SVG Integration
I think the main focus of the SVG Integration spec is the security model that was started in "Referencing Modes for SVG". I do not think that this section is sufficient enough yet, but is a good start. For SVG we basically have the following integration scenarios that imply security considerations:

1) SVG as image (no cross-domain restriction)
2) SVG as document in <iframe> or in <object>/<embed>
3) As external resource (reference of <filter>, <mask> or shapes with <use>)

The SVG Integration spec should spend more efforts in describing these considerations and how to deal with them.

* Furthermore the section about Dynamic Sizing of SVG Content should cover the different integration scenarios for the intrinsic sizing abilities of SVG (including inline SVG in HTML).
* The encoding section should rather allow an integrating language (like HTML) to overwrite the encoding and parsing sections of SVG.
* Other sections should be integrated into SVG if necessary or can be moved into an SVG primer document. They should not be part of SVG Integration.

I would like to see some discussions and changes before we follow the resolution to publish a FPWD.

Greetings,
Dirk

[1] https://svgwg.org/specs/integration

Received on Thursday, 6 June 2013 21:28:57 UTC