W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

SVG Integration Module

From: Doug Schepers <schepers@w3.org>
Date: Wed, 25 Mar 2009 02:49:11 -0400
Message-ID: <49C9D3E7.3000803@w3.org>
To: SVG WG <public-svg-wg@w3.org>
Hi, Folks-

The recent SVG-in-HTML threads solidified something in my mind.  I think 
it might be a good idea for us to make an SVG Integration Module, to 
discuss default behaviors for how SVG can best be integrated into other 
languages (subject to the rules of that language, of course).  This 
would be useful for our discussions with the HTML and CSS WGs, and also 
with ODF, IPTV, and other languages where we expect SVG might be reused 
as a whole, or even referenced in part, as in the Widgets specs.

One disadvantage of SVG 2.0 is that it will likely take a few years to 
complete.  Making such a module now will let us integrate certain 
specific aspects that we'd like to spell out immediately, and we can 
always integrate it into SVG 2.0 later.

Based on the threads and on conversations with Cameron, here's some 

* must have clear tables that integrate all known SVG elements, 
attributes, attribute values, and methods
* should link back to normative definitions for all the above
* should be automated (derive lists from SVG 1.1, SVG Tiny 1.2, Vector 
Effects, Filters, Compositing, Transforms, etc. via script)
* must be normatively referenceable [1][2]
* should have revision history [1]
* may have case-insensitive string equivalents [2]
* must cover different embedding and referencing scenarios (may work 
with HTML & CSS WGs here), with different expected capabilities [3]
* must explain how to extend SVG properly (copying the chapter from SVG 
Tiny 1.2) [4]
* must address potential security issues (external references, circular 
references, that weird thing ROC brought up with pixel-sniffing)
* must address passed in parameters, fragment identifiers, etc.
* should cover other specific odds and ends with various elements
* probably should not introduce new features

To do this, especially the automation, we should look at what it would 
take to modify the existing build scripts, and also what changes we 
would have to make to our specs, if any.  The biggest hassle would be 
SVG 1.1, but we need to do something about that for 2nd ed, anyway.  We 
would have to give a serious look at all our RNGs, which we need to do 

Cameron mentioned that he was already looking at this issue, and was 
just thinking about replacing/supplementing the DTD fragments that are 
in SVG 1.1 with readable summaries of what element children are allowed, 
and what attributes are allowed.

What do y'all think?

[1] http://lists.w3.org/Archives/Public/www-svg/2009Mar/0212.html
[2] http://lists.w3.org/Archives/Public/www-svg/2009Mar/0218.html
[3] http://www.schepers.cc/svg/blendups/embedding.html
[4] http://www.w3.org/TR/SVGTiny12/extend.html#ForeignNamespacesPrivateData

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Wednesday, 25 March 2009 06:49:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC