- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Thu, 12 Jan 2006 15:45:29 +0100
- To: thomas.deweese@kodak.com
- Cc: www-svg@w3.org
Hi Thomas, On Jan 12, 2006, at 14:05, thomas.deweese@kodak.com wrote: >> It isn't the job of a renderer to inform users of errors in the >> content. That's the job of compliance verifying tools. > > Well except as I point out above the WG has defined it such that > there isn't a error, it's just an attribute that needs to be ignored. > So I'm not sure what your compliance tool is going to do. It's ignored by user agents, content checking tools are a different class of products. A content checking tool that didn't detect that an attribute was not conformant to the schema, the microsyntaces, the prose, etc. would be a very poor one. I would expect a good one to actually know about new elements introduced in 1.2 but red-flag them if you asked it to check against 1.1. In fact a quality content checker would also red-flag things that are perfectly conformant, for instance repeating the same property with the exact same value of every child of a <g> (and I can't count how many tools do this), orange-flag defining a gradient outside of a <defs>, etc. There is a difference between non-conformant content that causes the document to be in error (e.g. non-WF XML), non-conformant content that is unknown/unsupported and is ignored, and conformant content. For each of those a user agent (intended for users) should behave differently from a content checker or producer (intended for developers and their ilk). >> UAs aren't things that are made for developers, they're made for >> users. Users don't care, and they shouldn't. > > The users of some UA's don't care the users of other UA's do > care. Shouldn't the WG leave it up to the UA implementer to decide > if their users care? I think there should be as high as possible content-interoperability, so the behaviour of user agents should be well defined. The behaviour of content checkers however is another topic, I'm not sure it would be useful for the WG to constrain how developer tools work. >> But neither of the above are the most important reason for >> considering that the halt and catch fire approach of 1.1 was wrong, >> and needs changing. The major problem it has is versioning, and >> deployment of content using new versions. > > So the WG has deprecated the 'version' attribute? Or is > the WG officially blessing marking content as version="1.2" and > including elements/attributes from version 1.3/2.0 of the SVG > specification. No, if you use the version (or baseProfile) attribute there is a requirement that if it is a version or profile unknown to the UA it immediately provide a highly perceivable notification that the content is likely to be misrendered. This allows the content author to clearly indicate that she doesn't want people to try to view the document if they can't, and that they do so at their own risk if they do. This is very close to requiring all features (except that the UA can still try to render the document provided the user has been notified that there's a problem). >> If you want to create content that uses features from a new version >> but will degrade reasonably well to older versions the only approach >> defined by 1.1 is to use switch. This is impractical at best, and >> experience shows that authors simply don't use it. > > Well, as I recall Adobe Illustrator output does make quite a bit of > use of it - to protect it's proprietary stuff. Also in many cases you > will want to provide an alternate 'fallback' rendering of the > 'extended' > content - which would still require the use of the switch element. The switch element isn't deprecated, and it certainly has its uses. That being said, as soon as you start hand-coding -- as many people do -- it's already a lot to ask of developers that they know the features of SVG that they need, if they also need to know which version they came in then we're asking too much IMHO. The idea is that one can (and should) use switch for critical content that needs to be rendered lest the document be useless, but shouldn't need to for chrome (and if your chrome fails, it shouldn't cause the important message you're conveying to blow up). >> Switch does have its uses, but wrapping everything in a conditional >> is hardly better than testing navigator make and version in scripts >> as used to be done in HTML. > > Actually I would consider it much closer to feature testing > (especially with the 'requireFeatures' test attribute), and feature > testing appears to be widely considered to be the 'best' way to > handle this issue. It's one way, I don't think that it's that widely considered to be the best, or else I really don't see why Java still doesn't have a standard pre-processor (and heck knows it would be useful sometimes). >> This new approach means that deploying new content is much more >> straightforward. > > As is subverting the specification. There is very little a spec can actually do to prevent people from subverting it. No matter how well the spec is defined, nothing prevents a vendor from subverting it, and if that vendor has enough clout others will have to follow no matter what. Have you tried to do a test run on a large sample of SVG that's out there, say on Open Clipart? I've been running rather intensive tests of SVG compressors that originally expected to operate on conformant SVG and I can tell you there isn't much of it. Any of that could have turned into subversion. >> Incidentally, the TAG's work on versioning concurs that the >> MustIgnore strategy in vocabulary design is sound. It's also in line >> with strategies adopted by other WGs for their vocabularies. > > Then please deprecate the version attribute. If the intent is > to allow any content anywhere then there is absolutely no reason to > have a version attribute. Yes there is, see above. Besides the point is not to allow any content anywhere, it's to provide versionable content with much lesser difficulty to developers. Random content anywhere that does not use namespace facilities is not conformant, for instance it won't validate against the schema. All that's been really changed is the way user agents handle these. > I was always under the impression that the whole point of > the version attribute was so that UA's could up front decide that > they couldn't really handle the content (i.e. they had no hope of > being conformant) and thus fall back into 'display what I can' mode. Again, see above. > I would expect similar behavior from 'incomplete' implementations. > But I really see no reason why an implementation that knows the > complete > element list for SVG 1.2, see's the version="1.2" and still should be > forced to allow 'unknown' elements in the SVG namespace - other than > to allow for vendors to stick proprietary extensions into the SVG > namespace. If a UA sees version='1.2' it means that if it knows all of SVG 1.2 it can proceed without alerting the user that there is a problem. It does NOT mean that the content is guaranteed to be 100% 1.2, in fact it could contain some 1.7 or 2.4 content, simply that 1.2 is the level at which the document is known to be minimally useful. >> A spec can't stop vendors being stupid. > > I'm not worried about the stupid vendors, "evolution" tends to > take care of them. My concern is about intelligent vendors who > intentionally use required behavior like this to gain an unfair > advantage in the marketplace, given the Web's history I think this > is a fairly valid concern. With the new rule there is no reason for > a vendor to identify extensions by namespaceing them. The rule you are complaining about was pretty much only really implemented to a solid extent (that I know of) by Batik. Any intelligent vendor could have gained an unfair advantage in the marketplace, and still could right now. So what can the spec do about this? Apparently nothing, or very little (there are other ways though). At least we're making versioning more practical on the Web at large, and content authoring easier. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Received on Thursday, 12 January 2006 15:11:23 UTC