getCTM definition ambiguity

This is related to questions regarding the SVG 1.1 updated standards,
related discussion about the implementation of getCTM() is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=873106

The primary problem is that getCTM() is defined as:

Returns the transformation matrix from current user units (i.e., after
application of the
‘transform’<http://www.w3.org/TR/SVG/coords.html#TransformAttribute>
attribute,
if any) to the viewport coordinate system for the
nearestViewportElement<http://www.w3.org/TR/SVG/types.html#__svg__SVGLocatable__nearestViewportElement>
..

And the definition of nearestViewportElement() is:

The element which established the current viewport. Often, the nearest
ancestor ‘svg’ <http://www.w3.org/TR/SVG/struct.html#SVGElement> element.
Null if the current element is the outermost svg
element<http://www.w3.org/TR/SVG/intro.html#TermOutermostSVGElement>
..

The current transform matrix (CTM) is defined as:


For each given element, the accumulation of all transformations that
have been defined on the given element and all of its ancestors up to
and including the element that established the current viewport

By the definition of the getCTM() method, the set of elements which must be
included in the CTM calculation are {outer_svg, null}. Null cannot have a
transformation matrix, thus the result is undefined. Firefox currently
resolves this by returning a null SVGMatrix, though it could possibly throw
an exception as an alternative. The consequence of this is that it is
difficult and convoluted to get the transformation matrix from the outer
svg element's user space to viewport space.

On the other hand, the definition of the CTM indicates that the set of
transformations to include are the element and elements up to and including
the element which establishes the current viewport. For the outer SVG
element, this is not null as nearestViewportElement() would indicate
because null cannot establish a viewport. The initial viewport is
established by the outer svg element using the svg user agent to negotiate
with the parent user agent. Thus, the set of elements operated on is just
{outer_svg}. This does have a valid transformation, which transforms from
the outer svg element's user space to its viewport space, including
transformations caused by viewBox etc. This is the approach taken by
Chrome, Opera, Internet Explorer, and I suspect Safari, though I don't know
because I can't test on Safari.

Thus, the getCTM() method's definition does not necessarily always return
the CTM as its name would imply it does.

How should we resolve this ambiguity going forward? I'm in favor of the
approach taken by Chrome, Opera, and IE because otherwise getting the
transformation from the outer SVG element's user space to viewport space is
extremely difficult, and potentially quite slow as it must be calculated
using javascript.

I propose rewording of the getCTM definition to the effect of:

Returns the CTM matrix, as defined as the accumulation of all
transformations that have been defined on the given element and all its
ancestors up to and including the element that established the current
viewport. The outer SVG element establishes is own viewport (this last
sentence may be redundant).