- From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Date: Wed, 18 May 2005 07:08:43 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>, www-svg@w3.org
Boris, Thanks for your reasonableness! Actually, I think Ian's point of view (shared by others) definitely needs to be taken into account, but so do the other points of view relative to reducing spec/testing/implementation complexity, and the various comments about the risk that if you define error handling too precisely people purposely will start creating nonconformant content that purposes is in error so that they can treat error handling as a language feature (instead of creating conformant content). We need to look at each of these cases on an individual basis. Regarding out-of-range integers, my opinion is that the ideal solution would be that validator tools are available which perform this check. I realize that no such SVG validator tools exist today, but if I were working on an SVG authoring tool, I know that this would be one of the features I would put into the tool. I think it is better for this check to be performed during the content generation process versus requiring viewers to perform this check when they receive the content. It is hard enough to implement a performant SVG viewer as is. In a previous email I had suggested that out-of-range integer values should be defined to be an error, with a hyperlink to the error processing section. Now I am reverting back to the opinion that out-of-range integer values are handled in a user-agent-dependent manner, but with a recommendation that user agents treat out of range values as an error. In other words, put the burden on the content creator. Jon At 08:33 PM 5/17/2005, Boris Zbarsky wrote: >Doug Schepers wrote: >>I think Ian's comment is well placed. With the proliferation of viewers >>pending, authoring will be a bear unless we shoot for as much consistency as >>possible. Alos, explicit treatment of each case during design is the best >>way to expose possible unforeseen problems. > >The problem, I would guess, is SVG running on a device that can't natively >represent integers outside that range. If SVG requires detecting integer >overflow, basically, then a lot of the sting-to-number conversion routines >get a lot more complicated (since you can't simply convert into a native >integer). > >-Boris
Received on Wednesday, 18 May 2005 19:46:13 UTC