tests that differentiate between SVG 1.1 Tiny, Basic and Full

Take for example struct-cond-03-t:

  http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/struct-cond-03-t.html

This test will render differently depending on whether feature strings
corresponding to features required by SVG 1.1 Full implementations are
supported.  You can see that in the reference image, Batik supports
"http://www.w3.org/TR/SVG11/feature#SVGDOM", which causes the top
rectangle to say “This viewer does more than SVG Tiny” and for its
colour to be different.

We are not caring about SVG 1.1 Tiny and Basic now (right?).  Should the
test be allowed to pass if it does not support that SVG 1.1 Full feature
string?

My preference would be to change any tests that pass if Tiny or Basic
functionality is supported but Full functionality is not.  For example,
I just changed struct-dom-06-b:

  http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/svg/struct-dom-06-b.svg

The pass criteria used to be:

  If an implementation supports the ECMA Script DOM binding, then the
  image should show the following text: "The DOM API is supported".
  Otherwise, the following will show: "Removing DOM elements is not
  supported", and the background will be red. 

and I changed it to:

  The test passes if the text "DOM API is supported" is shown, the text
  "Removing DOM Elements is not supported" is not shown, and no red is
  visible.


(I would actually prefer it if all feature string support tests were in a
single test file.  People do look at numbers-of-tests-passed in test
suites, and having a number of tests that would fail if particular SVG
1.1 Full feature strings are not supported I think would “punish”
vendors for attempting to be more accurate with their feature string
reporting.)

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 10 December 2010 00:09:37 UTC