- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 25 Mar 2009 02:49:11 -0400
- 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 requirements: * 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 anyway. 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 Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Wednesday, 25 March 2009 06:49:21 UTC