- From: <thomas.deweese@kodak.com>
- Date: Fri, 13 Jan 2006 06:32:18 -0500
- To: thomas.deweese@kodak.com
- Cc: robin.berjon@expway.fr, www-svg@w3.org, www-svg-request@w3.org
Hi all, One more suggestion on this point. It appears that the model Robin has put forth is that there is some minimal version of SVG that is required to maintain the primary functionality of a page (let's call this is base version) and there is presumably a second version of the SVG specification that is required to provide the full functionality of the page (let's call this the full version). Thus I would suggest that a new version attribute be added, either baseVersion, or fullVersion and assign the other's role to version. So if we had baseVersion and version, you might see something like: <svg baseVersion="1.2" version="1.3" ....> This would indicate that you need at least an SVG 1.2 implementation to make any real sense of this document, but parts of this document use element's/attributes/values from version 1.3 of the SVG specification. Thus a 1.2 implementation would know that it should ignore unknown stuff, but 1.3 implementation would still be able to say - ahh I know all of the elements attributes and values from SVG 1.3 - so I can be strict with this content (I would go as far as to add a "SHOULD notify user of 'unsupported' values" to the SVG specification in this case - this wouldn't force UA's to notify but would offer a deterrent from adding new elements to the SVG NS). I don't think that needing to increment/add the full version attribute when you start including content from a new version of the specification is a large burden for authors. Also some UA implementers might want to provide a small notification when they only implement SVG 1.2 but the document uses elements from 1.3 (if only to prod users into downloading the next version ;). www-svg-request@w3.org wrote on 01/12/2006 10:08:54 AM: > > Hi Robin, > > Robin Berjon <robin.berjon@expway.fr> wrote on 01/12/2006 09:49:07 AM: > > > On Jan 12, 2006, at 14:18, thomas.deweese@kodak.com wrote: > > > This is possible but is not IMHO how the SVG spec is currently > > > written. > > > > > > If the WG wants to adopt your interpretation then I would suggest > > > making it clearer that the 'ignore' only applies to the rendering > > > and adding a fifth bullet to section 'C.2': > > > > > > * The UA MAY display a highly visible indication that an > > > unsupported element, attribute, property, attribute value > > > or property value was encountered. > > > > > > However, given Robin's responses on this topic I doubt the WG would > > > agree with your interpretation. > > > > I don't see what in my reply gives you the impression that we > > wouldn't accept such a comment. > > Because you don't seem to accept the notion that a UA can > warn the user on unsupported values/elements as this (if widely > implemented) would prevent including SVG 1.3 elements in a document > labeled as version="1.2" - something you have stated as a goal. > My reading of your comments indicate that you feel a UA MUST > silently accept unsupported values/elements. > > > If you feel that the specification is > > unclear on the fact that content checkers can display highly > > perceivable indications of all sorts of things (this includes non- > > conformant content that would not cause a UA to stop, but also > > perfectly conformant things that are bad ideas as I say in my > > previous post) then we certainly should add something. > > Note that I say 'UA' above not content checker. Can a Conformant > SVG 1.2 User Agent produce a warning on 'unsupported' values/elements? > Note that in many cases this will effectively render the content > 'unusable' as the warning (or similar variations) may be repeatedly > generated due to script/animation (say script updating the 'transform' > attribute incorrectly in response to mouse move events). > > If you add the above bullet to C.2 then my main concern on this > point will have been addressed. Content producers will no longer > be able to rely on 'silent ignore' for elements/attributes not in the > spec. However this will go against your stated goal of allowing > limited SVG 1.3 content in a document marked with version="1.2". > >
Received on Friday, 13 January 2006 11:32:30 UTC