RE: [SVGMobile12] more on data types

Bjoern,
The statement unfair and inaccurate to say " The Working Group rejected the idea" when in our response (http://lists.w3.org/Archives/Public/www-svg/2005Apr/0156 ) to your "Microsyntaces" email we basically agreed with 3 of your 4 points, and we have now in the latest Last Call draft put in changes which at least partially addresses your fourth point via fixes to some of syntax definitions for SVG's properties, such as including the definition of color inline within the SVG spec.

Regarding the lack of interoperability for the following content:

  height="100 user units or so"

I am over on the Jim Ley side of the argument about error handling. Don't put the burden on each implementation to have to validate each attribute value and don't slow down processing to perform this validation. Instead, put the content checking burden on the content creation side of the world. (Your comments about fixing the SVG spec to make it possible to develop SVG content validators fits this model. It is good to provide validation tools to content creators.)

Jon


-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] 
Sent: Tuesday, January 10, 2006 3:47 PM
To: Jon Ferraiolo
Cc: www-svg@w3.org
Subject: Re: [SVGMobile12] more on data types

* Jon Ferraiolo wrote:
>It seems to me that there are two reasonable ways to go:
>
>(1) Ian's model of having different syntax requirements for SVG's
>"presentation attributes" (i.e., properties expressed as XML attributes)
>than for CSS stylesheets. In this scenario, a value of "RED" for an XML
>attribute would be incorrect content whereas a value of "RED" within a
>stylesheet would work.
>
>(2) Unify the syntax for SVG's presentation attributes with the syntax
>used by properties contained within stylesheets. [But this gets us back
>into the unitless values discussion and other thorny questions.]
>
>It is sounding like most everyone is saying (1) is reasonable and also
>it is sounding like we can't agree on how the unification approach for
>(2) should work, and therefore Ian's proposal is looking good.
>
>If we go for (1), then SVG needs to add at least one test to the test
>suite which makes sure that implementations do not accept
>case-insensitive keyword values for presentation attributes. (That is,
>"RED" must not work within a presentation attribute.)

In http://lists.w3.org/Archives/Public/www-svg/2006Jan/0162.html I
pointed out a number of similar problems, and others pointed out related
problems like when parsing invalid transform lists. This is easy to
extend, e.g.

  <rect y="100" height="100 user units or so" width="100"/>

comes out as black square in ASV6, TinyLine, Amaya, yields in a fatal
error in Batik (probably the correct behavior), and as nothing in Opera9
and Mozilla.

Much of this is the result of the draft and SVG 1.1 not properly
defining syntax for attribute values as I pointed out for example in
<http://www.w3.org/mid/4334e9c1.138323718@smtp.bjoern.hoehrmann.de>.
The Working Group rejected the idea to define SVG conformance as
"unnecessary burden on the specification editors".

For presentation attributes specifically, there aren't so many good
reasons to do (1) instead of (2).
-- 
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, 11 January 2006 00:07:35 UTC