W3C home > Mailing lists > Public > www-svg@w3.org > September 2005

Re: [SVG] assigning to currentScale

From: Rick <graham.rick@gmail.com>
Date: Tue, 20 Sep 2005 16:12:13 -0400
Message-ID: <18569e000509201312445a0fe7@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:31 GMT