W3C home > Mailing lists > Public > www-svg@w3.org > February 2008

Re: SVGt 1.2 Tests: 3 possible problems in struct tests

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 15 Feb 2008 12:14:04 +1100
To: www-svg@w3.org
Message-ID: <20080215011404.GE12726@arc.mcc.id.au>

Hi Kalle.

Kalle Raita:
> Our opinion is that the following 3 struct tests are faulty as detailed
> below.
> == struct-svg-201-t ==
> >From line 54:
> 	var fs = svg.getFloatTrait("snapshotTime");
> 	if(fs == "3")
> 	{
> This amounts to a float value compared against a string, which
> is a type mismatch.

In ECMAScript, the number will be converted to a string and the strings
then compared, so that code is OK.

> Moreover, constructing floats from strings cannot be guaranteed produce
> same result across implementations.

They should be, since ECMAScript mandates IEEE-754 floats.

> The returned float valued could theoretically be in this case 2.99999
> or 3.000001 depending on implementation. 

Theoretically that could be true, though.  SVG Tiny 1.2 only says this:

  <number> (real number value): A real number value is specified in
  either decimal notation or in scientific notation. A <decimal-number>
  consists of either an <integer>, or an optional sign character
  followed by zero or more digits followed by a dot (.) followed by one
  or more digits. A <scientific-number> consists of a <decimal-number>
  followed by the letter "e" or "E" followed by an <integer>. 

  Conforming SVG Tiny 1.2 content must use <number>s which have no more
  than 4 decimal digits in the fractional part of their decimal
  expansion and are in the range '-32,767.9999 to +32,767.9999'. It is
  recommended that higher precision floating point storage and
  computation be performed on operations such as coordinate system
  transformations to provide the best possible precision and to prevent
  round-off errors.
   — http://www.w3.org/TR/SVGMobile12/types.html

So technically while there are requirements on values used in content,
there are no restrictions on how those values are represented
internally.  I think though that it is very unlikely that the internal
representation used for float trait values is able to represent the
value ‘3’ exactly.

> Suggested fix: Get trait as string or require that 2.999 < fs < 3.001.

We resolved to leave this as it is.  Some other tests in the test suite
do perform such comparisons, though.

> == struct-svg-203-t ==
> The test uses SVG 1.1 Basic features and the reference image shows the
> result for an implementation that supports SVG 1.1 Basic. The test
> does not in any way indicate that both results are acceptable. What is
> the purpose of this test from the SVGt 1.2 conformance point of view?
> Suggested fix: remove this test entirely.

The test instructions in the document explain the pass criteria for SVG
Tiny 1.2 user agents, which isn’t simply comparing against the reference
image, so this should be OK to leave as is.

> == struct-discard-202-t ==
> >From line 25:
>       <rect x="100" y="50" width="100" height="100" fill="red">
> 		<discard xml:id="discard1"
> begin="circleanim.repeat(1)"/>
> 	</rect>
> And line 44
> 	<discard xlink:href="#discard1" begin="1s"/>
> circleanim.repeat(1) should happen at 5s, so the latter discard gets
> executed at 1s and discards the discard animation at line 26. The
> reference image suggests that the expected result is that the discard
> at line 26 gets activated and the top-left circle is exposed.

This was intended to be a negative test ensuring that repeat timing
specifiers in <discard>’s begin="" attribute are ignord, since they are
specifically disallowed.

However, in another discussion during our F2F this week we realised that
this restriction doesn’t make much sense, and resolved to make the
syntax of that begin="" attribute just the same as for the other timed
elements (such as <animate>).

So this test is currently being revised.

Thanks for your feedback!

—for the SVG WG

Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au
Received on Friday, 15 February 2008 01:19:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:13 UTC