- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 15 Feb 2008 12:14:04 +1100
- To: www-svg@w3.org
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! Cameron —for the SVG WG (ACTION-1841) -- 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