- From: Rick <graham.rick@gmail.com>
- Date: Tue, 20 Sep 2005 16:12:13 -0400
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Jonathan Watt <jonathan.watt@strath.ac.uk>, www-svg@w3.org
On 9/20/05, Boris Zbarsky <bzbarsky@mit.edu> wrote: > > Jonathan Watt wrote: > > I don't see how it violates the specification. I haven't seen anything > > to say that implementations "must not throw errors except as described > > in this and other applicable recommendations". > > That's because imposing such a constraint on implementations is unreasonable. > For example, I have yet to see a specification that describes throwing out of > memory exceptions, and at the same time implementations that _are_ out of memory > are far better off throwing said exceptions than just silently doing completely > incorrect things. In my opinion, of course. Correct. These are implementation issues and beyond the scope of the spec. The spec defines a graphic description language and cannot determine what an implementation should do when it nears the limits of the CPU, memory resources, integer/float register width, display capabilities, etc., of the platform it is running on. Doing so would involve dictating how implementors should write their code, which is unreasonable, would not be welcomed, and is frankly impossible. On the other hand, SVG attempts to define what implementations should do when the SVG markup is incorrect, which in my opinion is the correct place to draw the line. (pun intended :) > DOM 3 Core actually has explicit language to this effect, for example [1]: > > Implementations should raise other exceptions under other circumstances. For > example, implementations should raise an implementation-dependent exception if > a null argument is passed when null was not expected. > > -Boris > -- Cheers! Rick
Received on Tuesday, 20 September 2005 20:12:24 UTC