non conforming <number> and <length> treatment in SVGT1.2

Hello www-svg list,

Chapter4 Basis Data Types of SVGT1.2 notes about <number> (<length> refers 
to <number> too):

'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'.'

http://dev.w3.org/SVG/profiles/1.2T/publish/types.html

And in appendix C.2 it is mentioned:
'For known elements in the SVG or XML Events namespaces, unknown attributes 
that have no namespace and known attributes with unsupported values are 
treated as if they hadn't been specified when rendering. Unsupported values 
are defined in the definitions section.'

http://dev.w3.org/SVG/profiles/1.2T/publish/implnote.html

And in the definitions section:
'unsupported value:
An unsupported value is a value that does not conform to this specification, 
but is not specifically listed as being in error. See the Implementation 
Notes for more detail on processing unsupported values.'


If we have for example a rect element and an author used to write SVG 1.1
content accidently notes width="0.54321" in a SVGT 1.2 document, does
it really mean, that the rectangle is not rendered?
This is because '0.54321' is a value, that does not conform to the
specification, therefore such an attribute is treated as if it had not been
specified, therefore width of a rectangle is interpreted as zero and this
disables rendering of the element. 
Similar things happen to a complete path, if one number in the d attribute 
is for example '0.00001' instead of '0' (or even worse '0.00000' generated 
by a stupid script), or it maybe creates an error message.

Is this really the intended behaviour? 
What do other authors think about the current behaviour?
What do implementors think about it?
Maybe it fits more to the current SVGT 1.2 'design' to cover such 
errors simply by rounding such wrong number/length to  4 digits by 
the user agent?
If it is really intended as something like a help to the author to indicate
such wrong values, it might be useful to add a test to the test suite
(and to check that there are no such values accidently in the test suite;
I provided already an update last year for one of my test samples, containing 
such values accidently - this indicates already, that this really happens, 
especially if content is generated automatically with scripts)?

Received on Friday, 1 August 2008 14:33:29 UTC