Re: [widgets] Dropping xml:lang on icon elements

Robin Berjon wrote:
> Hey Marcos,
>
> On Oct 9, 2009, at 16:07 , Marcos Caceres wrote:
>> On Fri, Oct 9, 2009 at 3:42 PM, Robin Berjon <robin@berjon.com> wrote:
>>> On Oct 9, 2009, at 13:33 , Marcos Caceres wrote:
>>>> For simplicity, keeping a two-dimensional lookup of media type ×
>>>> locales folder makes the implementation easiest and yields the least
>>>> surprises.
>>>
>>> Fine by me, so long as it doesn't delay the spec any further :)
>>
>> I don't appreciate these "delay" statements. The only thing that is
>> delaying the CR process is that few implementers are sharing their
>> implementation experience and that I'm having to create test and
>> verify the spec on my own (and me having to waste time repeating in
>> emails what the purpose of CR is!). These icon bugs were caught by
>> Opera because Opera is turning the theory outlined in P&C into
>> practice.
>
> So it's great that Opera is finding bugs and reporting them, and it
> sucks that others are not finding or not reporting them — which might
> just mean that Opera is farther ahead in its implementation.

How for Opera along is irrelevant. Opera has no public builds. But I'm 
assuming you've seen these:

Windows Mobile
     Windows Mobile 6.5 Developer Tool Kit
 
http://www.microsoft.com/downloads/details.aspx?FamilyID=20686a1d-97a8-4f80-bc6a-ae010e085a6e&displaylang=en
BlackBerry
     BlackBerry Widget SDK 1.0 Beta 1
     http://www.blackberry.com/developers/widget
Wookie
     Wookie Engine 0.9
     http://getwookie.org/Engine.html
BONDI
     BONDI SDK for Eclipse 3.5
     http://bondisdk.limofoundation.org/

AFAIK, neither Microsoft nor RIM have provided any feedback. Feedback 
from Bondi WRT implementation experience of the CR doc has been limited 
(if any). AFAICT, given that all of the above are public, we can throw 
our test cases are those implementations and see what they have 
implemented.

> But that doesn't change one fundamental fact: this is a change "for
> simplicity", i.e. unless I misunderstood something not a bug that
> prevents interoperable implementation. So I'll re-state my position: if
> it causes no delay than already incurred, I'm happy to make
> implementers' jobs easier, otherwise I think it should stay as is. It's
> just the same argument I've been making all along: it's never going to
> be perfect, but it could well be too late.

Tell me, because I'm obviously slow, how the hell can the spec progress 
to PR if no one can pass the test suite? That is, if the assertions of 
the spec don't match the reality of what has been implemented by those 
listed above. And if the implementations above chose to deviate from the 
spec for valid reasons (e.g., Opera chose not to implement xml:lang on 
icon), then should we not be trying to understand why? Or do we 
grudgingly push forward pretending that our spec is perfect and then get 
all pissed off because no one is implementing it properly?

The only yard stick we wield in terms of conforming behavior is the test 
suite and the forthcoming Widget Compatibility Matrix (PPK's + other one 
I'm helping to cook up). I'm putting all my energy into the test suite 
as its the only way that what I wrote in the spec can be formally 
understood (i.e., if tests FAILs then, according to the W3C, you've 
implemented the spec wrong).

Kind regards,
Marcos

Received on Monday, 12 October 2009 14:50:09 UTC