Re: [SVGMobile12] Comment: Please give specific error-handling behaviour

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