Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior

On Sat, 11 Jun 2011, Arthur Barstow wrote:
> On Jun/10/2011 3:05 PM, ext Ian Hickson wrote:
> > On Fri, 10 Jun 2011, Arthur Barstow wrote:
> > > >
> > > >  My take on the comments is that most commentors prefer the spec to be
> > > >  changed as PLH suggested in comment #5:
> > > >  >  http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c5
> > > >  >  Hixie - are you willing to change the spec accordingly?
> >
> > What's the rush here? This is a minor issue, which I plan to address 
> > in due course. It's not blocking implementors, it's not causing any 
> > interoperability trouble, it's not stopping someone from writing a 
> > test suite, why all the fuss?
> 
> I would like all of the group's specs to keep moving forward on the 
> Recommendation track. That is an expectation set forth in the group's 
> charter and I don't think I have ever asked the group to "rush" this or 
> any other spec. (On the contrary, I have supported longer review periods 
> when requested and do not enforce the 90-day heartbeat publication 
> policy "just to publish".)

The recommendation track is an archaic mechanism. We shouldn't do things 
just because they are in charters or process documents, we should do 
things because they make sense and improve the Web.


> In this case, at least one other spec (which is planned for Proposed 
> Recommendation in early August) has a normative dependency on Storage 
> (and these functions in particular). Although the reference policy 
> provides some flexibility, I think it is sub-optimal for later stage 
> specs to depend on specs that are still changing.

I would be absoluely fine with Web Storage going to REC right now. There's 
no reason we need to gate on this particular issue. You can go ahead and 
publish the doc as LC, CR, PR, whatever it is you need.

Heck even if the spec wasn't ready according to the process document, 
there's ample precedent in the W3C for publishing documents completely in 
violation of the process. XHTML never had a test suite before going to 
REC, for instance. SVG went to CR with literally dozens of open issues 
and didn't even report half the formal objections. Nobody else follows 
process, why should we?


> I would appreciate it, if you would please provide a date when you 
> expect to have addressed this issue.

That's not how this works.


> (FYI, Cam is working on a schedule to move Web IDL to LC which is the 
> only other dependency not yet at LC for the spec mentioned above.)

And what will happen to Web IDL when we find that we need to change 
something? Web IDL is a core platform spec, it's not like it's ever going 
to be finished.


The particular issue in question isn't a particularly important one. The 
spec describes a superset of implementations, and is a logical direction 
for the spec to go. (Even within the process, there's no reason we 
couldn't go to LC with it as is.) Implementations are the ultimate guide 
here, when this issue bubbles up to the top of the priority list then 
it'll get resolved one way or the other based on what they do and want.

However, I'm not going to arbitrarily prioritise issues just for 
bureaucratic reasons. (This isn't a trivial issue to resolve, it would 
take me a few hours of carefully asking questions of the various browser 
vendors.) There are far bigger fish to fry right now on the Web platform 
than whether or not vendors' long-term plans include supporting File 
objects in localStorage, or what not.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 11 June 2011 19:10:51 UTC