Re: SVGT 1.2: Appendix C3: SVG Error Processing

On Jan 8, 2006, at 11:43 PM, David Woolley wrote:

>
>> But either approach would be acceptable, so long as it is clearly
>> specified.
>
> True from an engineering point of view; not necessarily true from a
> marketing point of view.

I would hope that W3C specifications are meant to be engineering  
documents, not marketing documents.

>   From a marketing point of view, early products
> and late products tend to differ.  For early products, time to  
> market, and
> development costs, are critical, and the preference tends to be to  
> implement
> code which doesn't check for anything except valid constructs  
> (which is
> where acceptance of tag soup in HTML came frome).  For late products,
> active error recovery becomes an area of competition, and then the
> objective is to handle real life errors in the way least likely to  
> result
> in the viewer realisng that the author made an error.

Fortunately, conformance with a specification (especially if somewhat  
verifiable via test suite) is itself a marketable, therefore  
specified error handling tends to work against a competing "guess the  
intent" arms race. Consider for example CSS, where neither of the  
phenomena you mention have come up, and indeed all browsers are  
moving to be more strictly conforming with their parsing, even IE7  
plans to do so. (Or, for a lower-level example, consider TCP/IP,  
where being "tolerant" of invalid packets is considered actively  
harmful.)

That's why I think this issue is important. Better for SVG to end up  
like CSS in this regard than like HTML.

Regards,
Maciej

Received on Monday, 9 January 2006 10:26:37 UTC