W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

Re: [SVGMobile12] more on data types

From: Jim Ley <jim@jibbering.com>
Date: Thu, 12 Jan 2006 09:56:54 -0000
Message-ID: <00c401c6175f$2cd1b270$0700a8c0@Snufkin>
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: "Robin Berjon" <robin.berjon@expway.fr>, <www-svg@w3.org>

"Bjoern Hoehrmann" <derhoermi@gmx.net>
>>that's easily correctable too, and if you then write the rules that say 
>>how
>>to correct that what do you do with the next example, and the next, and 
>>the
>>next.  If these rules are left up to implementations (and I would of 
>>course
>>encourage implementations to agree on error recovery like this) then more
>>things can be recovered than those that are thought of now.
>
> If the specification does not define how to process the above, and you
> allow implementations to process it in any way they choose, the effect
> is that you allow implementations to extend the semantics of the format
> which later limits how *you* can extend the semantics of the format. A
> simple example is

Certainly, however I fail to see the dis-advantage in having to have 
attributeX in the new version if you want to extend the semantics, it's 
cleaner, it avoids all versioning issues, and is simpler for the authors as 
there can be no confusion, you can even have both attributes simultaneously 
to degrade absolutely in all conformant viewers.

A "Stop and display Error" when older UA's meet new content does not 
degrade.

> This is perfectly legal SVG 1.1 content, but Tiny does not support this
> and e.g. TinyLine renders this as if

Indeed, that was a good example of how differences in the content of a 
single attribute is difficult, it fails to show how an error strategy of 
"stop on error" makes content degradeable.

Jim. 
Received on Thursday, 12 January 2006 10:02:05 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:33 GMT