W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [widgets] <option>s on <feature>s

From: Robin Berjon <robin@berjon.com>
Date: Wed, 18 Mar 2009 23:22:54 +0100
Cc: public-webapps WG <public-webapps@w3.org>
Message-Id: <153DA642-1DD9-4395-9863-5BCBE2665D28@berjon.com>
To: Arve Bersvendsen <arveb@opera.com>
On Mar 18, 2009, at 16:37 , Arve Bersvendsen wrote:
> On Wed, 18 Mar 2009 16:19:34 +0100, Robin Berjon <robin@berjon.com>  
> wrote:
>> On Mar 18, 2009, at 15:38 , Marcos Caceres wrote:
>>> It might be good to add an <option>s element on the <feature>  
>>> element to allow options to be set for features using name-value  
>>> pairs. For example:
>>>
>>> <feature name="http://clothing.com/api">
>>> 	<option name="fancy" value="pants"/>
>>> 	<option name="color" value="green"/>
>>> </feature>
>>
>> Do you have some examples that involve things that aren't pants?
>
> Does this suffice?
> <feature name="url_describing_filesystem_api">
> <option name="music" value="read" />
> <option name="video" value="read write" />
> </feature>
>
> The intent would be to allow a widget UA to allow native UI for  
> selecting this, not dependent on for instance browseForDirectory().

I see a limited use case for the sort of example you propose, but I'm  
nevertheless going to push back against it. One reason is that it can  
already be described with features, to witness:

<feature name="url_describing_filesystem_api/music/read"/>
<feature name="url_describing_filesystem_api/video/read"/>
<feature name="url_describing_filesystem_api/video/write"/>

(and it's even one line shorter, without even having had to try).

But one more important objections is that we're in Last Call. During  
Last Call, the only changes that should be made are bug fixes, and  
only in the very rare cases when something demonstrably really, really  
important can't happen feature changes. I don't think that this  
suggestion, irrespective of its potential merit, falls in either  
category.

Some people on the WG might believe that document maturity on the Rec  
track doesn't really matter, or at least that LC is just like another  
WD. It does, and it's not. If your friends are waiting for you at a  
bar and you're on the phone telling them "yeah, I really am just  
around the corner, I'm coming right now!", and you do that several  
times in a row until the beer they'd bought for you is out of bubbles  
and your Gammel Dansk has all but evaporated, they're not going to be  
happy, and they won't take you seriously, and they won't buy you  
drinks next time. And that pretty girl/boy/alien will probably have  
left home, crying.

It's the same here. People outside the WG, and outside the W3C, have  
made plans based on when this spec was announced to be shipping. Every  
time the spec is pushed into another LC  which is required for new  
features and any major normative change  you risk breaking those  
plans. You can't ask for people to wait for you to finish and at the  
same time default on your word every time you say you're just around  
the corner.

This is not just about synchronising with Bondi (even though that's  
part of the issue), it's about the fact that vendors are going to  
start implementing what's there pretty soon in order to ship on time,  
whether the spec is ready or not. And if the spec isn't ready enough,  
then it won't be about implementing a potential Bondi snapshot of a  
WD, it'll just be about going full proprietary. Yes I could make a  
case against them for that, but no it's not going to make any  
difference. And even if it would, all the time we spend delaying the  
spec and through that encouraging  whether we want it or not  non- 
interoperable and proprietary solutions is time that keeps the door  
open for AIR Mobile and Mobile Silverlight to grab the market.

If you think I'm exaggerating, consider this example: when SVG first  
went into CR, Flash didn't even have scripting. Then, things got a  
little bogged down.

I'm not saying that this group hasn't done amazing work, and I'm not  
picking on you Arve or Marcos, I'm just trying to encourage some focus  
and push away things that can go in 1.1 if we need them. I'm pretty  
sure everyone here has either ranted about W3C being slow or over- 
optimistic in its schedules, or at the very least nodded when someone  
else was doing that. Well, for those of us who are on the WG or  
otherwise participating, that's really up to us  not W3C management,  
or staff, or even the chairs, or our bearded CSOs. As the philosophers  
of days ancient so well taught us, with great power comes great  
responsibility. So let us all bask in the glorious light of the power  
bestowed upon us as Participants and (gasp!) Editors for a minute, and  
then pull the keyboard out and act like it.

Rant now officially over. Can we agree on a) being feature-frozen, and  
b) a list of blockers that absolutely must be exterminated before CR  
that we can then club to death with loaded Uzis?

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Wednesday, 18 March 2009 22:23:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT