- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Wed, 18 May 2005 20:24:39 +0200
- To: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Cc: www-svg@w3.org
* Jon Ferraiolo wrote: >There are a zillion ways content can be unconformant. If we specify >behavior for each possible non-conformant situation, the spec itself will >take an infinite amount of time, the test suite twice infinity, and the >implementation thrice infinity. If processing for specific input appears to be undefined, implementers would likely try to find answers to questions such as * Is processing really undefined? * Is processing considered "obvious"? * Has this issue been reported before? * Is it intentionally left out? * What could be good processing here? * What do other implementations do? report the problem to the working group, implement their best guess in a way that can easily be changed later to accomodate competing implemen- tations, conflicting errata, spec revisions, etc. and document what they implemented so additional tests can be written, etc. If processing is clearly defined in the specification, they would simply implement that, address bug reports with a pointer to the specification and keep the behavior, documentation, tests, etc. as-is. Your suggestion that well-defined error processing has considerable negative impact on implementations seems thus rather strange to me, perhaps you can provide some background material? -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Wednesday, 18 May 2005 18:27:31 UTC