TestCoverage/14-Linking

From SVG
Jump to: navigation, search

This page is an archive of the previous Group's wiki from http://www.w3.org/Graphics/SVG/Group/wiki.


Test Coverage for SVG Tiny 1.2 Chapter 14: Linking

[1]

Legend:

 - is a comment or note
  is an assertion or feature that is fully covered in the test suite
 # is an assertion or feature that is partially or not covered in the test suite

14.1 References

- In general, a set of template tests, one per element that takes an href, could then be copied and modified to make many of the tests below. Also one test that exercises all the elements-with-href.


# If the xlink:href  attribute of an element in the tree is altered by any means (e.g. script, declarative animation) such that a new resource is referenced, the new resource must replace the existing resource, and must be rendered as appropriate.
 - One test per element that takes an href, altering href with a set. Some of these are already tested, but its good to test them all.
 - Same tests but with script to replace the href attribute value via uDOM **must replace** is wrong, depends on the target attribute.


# An XML resource identifier (XMLRI) may contain characters that, according to [RFC 3987] and [RFC 3986], must be escaped before the string can be used to retrieve the referenced resource.
 - Several tests, one per element that takes an href. For each test, several subtests:
  • test international DNS (there is a server at keio, natto, which has an idns registration and can be used here)
  • test unicode characters in path
  • test unicode characters in fragment
  • test unicode characters in query. This needs a server-side component which tests the query has been correctly converted to utf-8 and escaped, and returns either a pass or a fail image.
  • test XRI (now called HRRI) to IRI by having an address with an unescaped space character. (eg My Documents)
 -  For each element listed in the first row of the table, one test. For each column that says 'yes', a subtest with that option.


#  A circular IRI reference shall represent an error (see Error processing).
 - One test (with just one subtest) with a direct circular reference A_> B -> A
 - One test (with just one subtest) with an indirect circular reference A_> B -> C -> A
 - One test (with just one subtest) with a direct circular reference from redirection A_> B -> C, where C redirects to A
 - For each test, have a big red 'FAIL' after the element with the circular reference; that element is not displayed because of the error.


# When attribute externalResourcesRequired has been set to true on the referencing element or one of its ancestors, then an unresolved external IRI reference (i.e., a resource that cannot be located) shall represent an error (see Error processing).
 -  Several tests (one per referencing element - gradient, image, etc), each with eRR and subtests pointing to
  • a non-existent resource
  • a resource that does not resolve, eg a gradient pointing to a text file
 - The value of the href  attribute must be an XML Resource Identifier. This is a statement that was originally "is" and got changed to "must". But its not testable. Given that the set of URI protocols is extensible and that we have relative references, any string is a plausible web address. Suggest we change this to: Note: the value of the href attribute is an XML Resource Identifier [XLink11] except we should point to HRRI instead. Note that the spec then goes on to say this "Because it is impractical for any application to check that a value is an IRI reference, this specification follows the lead of the IRI Specification  in this matter and imposes no such conformance testing requirement on SVG applications."


# If the IRI reference is relative, its absolute version must be computed by the method of [XML-Base] before use.
 - One test per element-with-href, using relative references. Several subtests as below. Not all elements have all subtests (eg if fragments are not allowed, no fragment subtest and strip frags from the others. If only same-document references are supported for that element. Plus:
  • relative reference with #foo


# This attribute is provided for backwards compatibility with SVG 1.1. It provides documentation to XLink-aware processors. In case of a conflict, the target attribute has priority, since it can express a wider range of values. 
 - A test with conflicting show and target values, passed by doing what target says.


# Each primary document must have an associated dictionary that maps all IRIs for resource documents it references; initially it is populated only with the primary document itself. Each resource or subresource loaded directly or indirectly must be resolved through that dictionary with resource documents downloaded as needed. The conceptual model is that each resource document is loaded only once; if the same resource document is referenced multiple times directly or indirectly by the same primary document, that resource document is only retrieved and processed one time.
 - test has two animation elements. One points to resource.svg, which is animated, the animation completing and freezing after 2 seconds. (a combination of scripting and animaton, would be better). After 4 seconds, the other animation element in the test has its href changed with a set to point to resource.svg as well. This second reference points to the same instance as the first, so the animation has already happened. After 6 seconds, some combination of animation and scripting makes further changes to resource.svg and both renderings of it move in sync.


# Because of HTTP redirects, the same source document might be retrieved from multiple different source IRIs. The rule for SVG is that documents are considered to be unique based on string comparisons of the full IRI after resolving relative IRIs into absolute IRIs and after taking into account HTTP redirects (i.e., use the post-redirect IRI instead of the original source IRI)
 - same as the previous test, except the first animation element points to a copy of resource.svg on the web, and the second animation element points to redirect.svg which does an HTTP redirect to resource.svg.

- this part of the spec was changed, since implementations don't do this post-redirect comparison as it breaks the web


14.2 Links out of SVG content

# A simple link is defined for each separate rendered element contained within the 'a' element; thus, if the 'a' element contains three 'circle' elements, a link is created for each circle. For each rendered element within an 'a' element, the given rendered element is the local resource (the source anchor for the link)
 - test has an a element with multiple children, one of which is a path with multiple subpaths. test that each rendered element works as a link anchor


# (target) This attribute should be used when there are multiple possible targets for the ending resource, such as when the parent document is a multi-frame HTML or XHTML document. This attribute specifies the name or portion of the target window, frame, pane, tab, or other relevant presentation context (e.g., an HTML or XHTML frame, iframe, or object element) into which a document is to be opened when the link is activated. The values and semantics of this attribute are the same as the WebCGM Picture Behavior values [WebCGM]
 - Test each of the specified values for target, or at least the ones that can be tested in an svg-only test.  This should also look at the WebCGM20 picture behaviors http://www.w3.org/TR/webcgm20/WebCGM20-IC.html#webcgm_3_1_2_1 and Dougs tests on target, and  be totally clear how this works for things that create a frame and things that don't. Only some of this can be SVG tests; the rest needs to be CDF tests (but we should still create them, via people who are in both WGs).

14.3 Linking into SVG content

# To link into a particular view of an SVG document, the IRI fragment identifier must be a correctly formed SVG fragment identifier. 
 - Its not clear how that is a testable assertion, except to test that junk syntax doesn't do anything.


# If no SVG fragment identifier is provided (i.e., the specified IRI did not contain a "#" character, such as someDrawing.svg), then the initial view into the SVG document shall be established using the view specification attributes (i.e., viewBox, etc.) on the rootmost svg element.
 - Already tested, although check that there are viewbox tests.


# If the SVG fragment identifier addresses specific SVG view (e.g., linking-svgView-102-t.svg#svgView(transform(rotate(30, 150, 150)))), then the document fragment defined by the closest ancestor 'svg' element is displayed in the viewport using the SVG view specification provided by the SVG fragment identifier.
 - Already somewhat tested; in tiny the closest ancestor svg == the rootmost svg. Test all the different forms of syntax allowed by the BNF, ie with single and multiple transforms; with rotate, shear, etc.


# If the SVG fragment identifier addresses any element (e.g., #rectId  or someDrawing.svg#rectId) and the element indicated by the fragment identifier is found, then the current translation of the SVG document's coordinate system shall be adjusted such that the centerpoint of the decorated bounding box of the identified element is positioned in the center of the viewport. 
 - This is new with SVG 1.2. Several tests, with same-document references:
  • point to a plain axis-aligned rect, untransformed, with no stroke. Indicate the center point with some other graphic (same for all these tests and place a filled and stroked rect behind which should exactly fill the viewport.)
  • point to a scaled, rotated and skewed rect, no stroke
  • point to a path with a thick stroke (it seems that in Tiny1.2, stroke is the only thing that affects the decorated bb)
 Another set of tests which point to the above tests as external references.


- **NOTE**  The painting tests might use linking as a way to test the assertion: "This property contributes to an element's  decorated bounding box"  eg for stroke-linejoin; use bevel, round and miter with acute angles and a suitable value of miter-limit to ensure that there are big spikes for the miter case.


# If the element's decorated bounding box is too large to fit within the current viewport, and the zoomAndPan  attribute of the rootmost svg element is not set to 'disable', then the viewport shall not only reposition but also have the current scale expanded to accommodate the entire width and height of the element's decorated bounding box.
 - point to a rect which is bigger than the current viewport, but whose center is inside the viewport
 - point to a path with a thick stroke whose decorated bbox center is outside the default viewport
 - Same again but as external references.


# If the specified element is not found, or does not have a decorated bounding box, then the current translate and current scale are not changed from the established values. 
 - Three tests, firstly with a frag not found, secondly with a frag that points to a zero-width rectangle, thirdly pointing to a gradient.


- Regardless of changes to the current translation or scale of the viewport, the current rotation of the current coordinate system shall be preserved (that is, the centerpoint of the target decorated bounding box shall be the centerpoint of the rotation, with a constant rotation angle), and the existing aspect ratio shall not be altered.


- I might need to discuss the intent of that one before suggesting tests. Current coordinate system on while element - the link anchor? The link target? the svg element?


# In the case of traversal from an external link, the viewport shall be established by the values specified in the rootmost svg element
 - Link from one svg element to another, using a frag to a path, check the viewport is correctly positioned.


# and in the case of an internal link, the initial viewport shall additionally be adjusted by any previous zooming operations (e.g. previously navigated links, user zooming, script alterations of the current coordinate system, etc.) such that any translation or scaling that happens as a result of the traversal shall use the existing coordinate system as a starting state.
 - Three tests, one for each of link traversal, user zooming and script modification of the coordinate system. Leave etc untested for now :)


# In all cases of traversal, the view shall be established instantly, with no animated panning or other enhanced transition toward the target element. The viewbox shall not be continually animated to match the animations of a target element's decorated bounding box.
 - First part is tested by the above tests noting that link traversal must result in an instant change rather than a zooming or panning animation. Second part; test links to a path whose shape and whose stroke-width are animated. Tricky to phrase this so the user has enough time to traverse the link, they always see the same thing, and don't have to wait for an animation to start. Can the animations be triggered by pointer events on the link target, with a +2s offset?