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

Re: [SVGMobile12] SVGT12-207: Too many issues (again)

From: Marc Verstaen <marc@beatware.com>
Date: Wed, 1 Feb 2006 13:51:09 -0800
Message-Id: <19A957FF-9659-4212-9D23-E7CE1118C9DE@beatware.com>
Cc: www-svg@w3.org, "'Bjoern Hoehrmann'" <derhoermi@gmx.net>
To: Maciej Stachowiak <mjs@apple.com>
I think I understand what a spec is. But the goal is not to release a  
spec for the sake of releasing a spec. The goal is to release a spec  
that will be used by implementors on mobile devices. Right now, some  
of the major implementors of SVG on mobiles have already implemented  
SVG-T 1.2. Holding on on the release of the spec is only helping to  
kill SVG.

The choice is not release now in a non-perfect state or release later  
when everybody will be happy with every word. The choice is release  
now and start releasing the implementation, or release later in a  
desert.

I realize that the situation is different on the desktop, where most  
players are still catching up with SVG 1.1. But this is not a valid  
reason to kill SVG where it is successful right now.

Marc



On Feb 1, 2006, at 10:21 AM, Maciej Stachowiak wrote:

>
> On Jan 31, 2006, at 3:58 PM, Marc Verstaen wrote:
>
>>
>> Considering the number of implementations for SVG-T 1.2 already  
>> available, I
>> am not this proves anything about the specs of SVG-Tiny 1.2. We  
>> are not
>> talking about SVG 1.2 here...
>
> The goal is not to have just any implementations but fully  
> interoparable implementations that meet the conformance  
> requirements of the spec. Without a thorough test suite, there's no  
> evidence that this is the case. And there are known ambiguities and  
> contradictions in the latest Last Call draft.
>
> Furthermore, if the spec requires things that are contrary to other  
> specs, it means certain classes of implementations (those that also  
> support other specs) cannot possibly be interoperable.
>
> Therefore, rushing the spec as-is will not be an aid to  
> interoperability. If some implementations can have de facto  
> interoperability that is nice, but we should not lock in a spec  
> that actually could actually harm interoperability.
>
> Regards,
> Maciej
>

Marc Verstaen
CEO - Beatware Inc.
Received on Wednesday, 1 February 2006 21:51:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:53 UTC