Re: making comma-wsp optional between points list coordinates

I have to say that I agree with Juergen in the general case, when he writes

consistency with other cases is always a good argument for a change. But in
> this case, I would have proposed to have a consistency to a notation which
> is _readable_, and _intuitively_ _understandable_ by _humans_ instead of
> allowing notations like "1.5.3-1,.2-.7e1.2.3" in any case


I definitely don't like the idea of encouraging people to smoosh all their
numbers together.  For one thing, it makes writing regular expressions to
parse values from scripts a serious pain.

(P.S. On that particular jumble of numbers, I was wrong -- the specs
clearly say that an exponent must be an integer.  But it does prove
Juergen's point!)

However, I do like the idea of inter-consistency between polygon and path.
As Cameron notes, many implementations already support the condensed form
-- probably because they are using the same path parsing code to handle
polygons and polylines.

I suggest something like the following language:

Authors and authoring agents SHOULD use a comma or whitespace or both to
separate values in a <list-of-numbers> or <number-optional-number>
datatype.  User agents MAY ignore errors from missing separators where the
value can still be parsed as distinct numbers according to the grammar in
the [Basic Data Types section].


(In other words, formalize the current situation.)

OR replace the "MAY" by "SHOULD" in the second sentence (i.e., encourage
*all* browsers, etc., to adopt the permissive behavior).

However, there's also a counter argument:  This approach will sometimes
cause very-difficult-to-debug errors if the author (or their script) has
put together a string of numbers that can be correctly parsed as numbers --
just not the numbers the author intended.

For example, my -.7e1.2 error.  If separation is always required between
subsequent numbers, drawing of the shape would stop right at that erroneous
coordinate, and I can easily track down the problem.  If separation is not
required, that gets parsed as two numbers (-0.7e1 and 0.2), and drawing
continues, but now all my coordinate pairs are jumbled up, creating a total
mess until it reaches the end of the list of points and there's an extra
number left at the end.  But the entire shape would be a mess and it would
be hard to figure out what was going wrong.

AmeliaBR