Re: [widgets] P&C, outstanding feedbac...
On Fri, Jul 3, 2009 at 7:35 PM, Marcos Caceres wrote: > I talked to our localization guys about this, they said that is > definitely not a good thing. They said any content is better than no > content, even if there is a mismatch. I've spoken w/ coworkers recently, and other people too, and the general spirit is "if the app is so poorly localized, and it usually is, they'd rather see it in the language where it isn't poorly localized that they actually understand" (typically English; the people in question are typically natives of Finland and surrounding countries and have have English as at best a second or often a third language) I suspect that in the end, as long as a user agent allows the user to see which localizations the widget has and for the user to express a more limited list of preferences for a given widget, this won't be a problem, and hopefully user agents will do this. > I agree, but that is Apple's fault. Yes, the model allows things like > this to happen. But I think it's better thank getting no license at > all. > I still feel that this is an author-level error. I don't like enabling authors to screw up localization, it's too easy to do already, and they've proven to be quite adapt at it locally. -- My experiences in the States didn't show these problems, but that's probably because I was being sold untranslated goods or goods by vendors who were more careful. > I agree this sucks, but like I said, my preference is to have > "something" shown. When authors make such mistakes, then can easily be > patched via updates, which is what updates are for. The iTunes example is unfixed to this day, a number of updates later. As is Nokia's flags example [1] and Centre (I got an update last week). > I agree. But again, iTunes should do something about that. It can't be > the case that widgets would not allow me to ship a widget because I > can't get something translated. > If that was the case, I would still > include the wrongly localized content just so I could ship I'd prefer for you to be aware that you're screwing your customer. Having to actively jump through a hoop "This is wrong, but I'm desperate and in a hurry, and know it's wrong" v. "I'm done, it's perfect, I'm never making any changes ever again" > (and just > say, "centre, center, meh! Only a few will notice, so I'll fix that in > the next update."). Bah, it's still not fixed, and I've complained both through the care number and internal feedback. [1] http://library.forum.nokia.com/index.jsp?topic=/Web_Developers_Library/GUID-63F29096-C1A3-45DB-9E2F-6110562E0237.html It's good to see no one fixes their bugs. I really look forward to widget updates being as useless as everyone else's updates in these areas.
Re: widgets feedback
On Fri, Jul 3, 2009 at 6:55 PM, Marcos Caceres wrote: > Addressed your final set of editorial issues. If satisfied with the > corrections, please give us > an OK for the DoC :) DoC: OK except for the one below. >> 4:37 PM A user agent will acquire a potential Zip archive from a data >> transfer protocol that either labels resources with a media type (e.g. >> [HTTP]) or from a data transfer protocol that does not label resources >> with a media type (e.g., BitTorrent, Bluetooth, etc.). >> >> A tautology ... >> (yes, i know we're trying to say this, but is there a better way to write >> it?) > > I think I will leave it. The point here is to alert the reader that we > handle both cases. Oh, I wasn't asking you to remove it, just rewrite it ;-) A user agent can acquire a potential Zip archive both from data transfer protocols which label resources with media types (e.g. ) and from data transfer protocols which do not (e.g. ...). I think you already got rid of the e.g.+etc. pair.
Re: widgets feedback
On Fri, Jul 3, 2009 at 6:37 PM, Marcos Caceres wrote: > Fixed all editorial comments below for this third set of comments. If > satisfied with the corrections, please give us > an OK for the DoC :) DoC: OK > This would be the author's fault for including an empty file. The UA > still does the right thing (it loads the index.svg file and finds it > is not well formed.) Should CC's be encouraged to complain about such things? I suppose not as it's fairly hard to determine if random start formats won't work...
Re: widgets feedback
On Fri, Jul 3, 2009 at 6:12 PM, Marcos Caceres wrote:
> If satisfied with the corrections, please give us
> an OK for the DoC :)
DoC: OK except for the bits below (and one's a long bit, it'll have to
wait for the week to start)
>> 9:40 AM The [Widgets-DigSig] specification also defines the naming
>> conventions for a distributor signature and the naming convention for
>> an author signature.
>> i think you want 'for distributor signatures' and 'for author
>> signatures' (plural for both)
>
> There is only one author signature. I don't want to imply there there
> can be more.
"an" => "an/the optional" ?
There can be multiple distributor signatures, right?
> Used "A start file designates the file from the widget package to be
> loaded by the user agent when it instantiates the widget."
{long discussion about default start file}
Sorry, I'll have to read this at some other time.
Re: widgets feedback
On Fri, Jul 3, 2009 at 5:12 PM, Marcos Caceres wrote: > Fixed issues below. If satisfied with the corrections, please give us > an OK for the DoC :) DoC: OK > I guess the person at Times Square that made the decision to activate > the widget. Oh well. Someday that user will be replaced by an automated random heisencat. I guess I'll just have to wait for that cat. > * sections marked with the text This section is non-normative, > *authoring guidelines, I hope there's a space after that bullet :) > * examples, including sentences that contain the words "for example", > * and notes. > > AFAIK, "that" is correct here. But I can't be bothered looking up a > manual of style. Yeah, I think you're right.
Re: Points of order on this WG
On Jul 4, 2009, at 7:43 AM, Charles McCathieNevile wrote: On Sat, 04 Jul 2009 16:03:48 +0200, Maciej Stachowiak wrote: On Jul 4, 2009, at 4:56 AM, Charles McCathieNevile wrote: We are "potentially interested" - i.e. we want to see how the spec comes out first. Given that this is in the scope of existing deliverables, and given taht Oracle are providing the resources to edit it, I see no reason to simply stand in their way. I think a B-Tree style storage API would clearly be in scope of existing deliverables. However, it's not clear to me that Oracles's other proposals (programmable http cache, request interception) are. As I understand it, those technologies don't really relate to storage, or even networking as such, but are meant to serve a role similar to HTML5's Application Cache feature. Also, Nikunj's request was to add these things to the charter, from which I infered the charter doesn't already obviously cover them. I disagree that neither relate to storage or networking. Oracle's proposals are about offline storage - programmable http cache is clearly offline storage and request interception is about offline processing and both involve networking. This is why we brought the proposal to Web Apps WG. I have explained why programmable http cache is different from HTML5 ApplicationCache [1]. As I noted in my earlier message to Nikunj, as far as we (chairs, staff contacts and domain lead) can see the features *do* relate to storage, and are in scope of the charter as is. So it's OK, you don't need to worry about the charter changing. It is good to know that the charter is based on scope rather than deliverables because, otherwise, every new proposal (even as an alternative approach) would need a charter change. Thanks for clarifying this. On Jul 4, 2009, at 4:56 AM, Charles McCathieNevile wrote: On Sat, 27 Jun 2009 03:06:21 +0200, Maciej Stachowiak wrote: On Jun 26, 2009, at 10:51 AM, Nikunj R. Mehta wrote: Secondly, Oracle proposes adding request interception and programmable http cache to the WG's charter. Oracle will provide resources for editing and reviewing proposals for all three deliverables. We already have a broad charter and quite a few deliverables. Before we add more to the charter, I'd like to understand the degree of interest in request interception and programmable http cache. Is anyone besides Oracle interested in pursuing this technology? Are any implementors interested in implementing it? We are "potentially interested" - i.e. we want to see how the spec comes out first. On Jul 4, 2009, at 7:03 AM, Maciej Stachowiak wrote: It's hard for me to evaluate Apple's interest in these technologies without seeing a concrete proposal for these features, so I definitely don't object to a draft. Although Oracle proposal on request interception and programmable http cache (doesn't include B-tree) was made public and distributed on this ML in April [2], it has not been made in to a formal member submission. I would understand if you are waiting for that to happen, but you can already see how concrete the proposal is. I appreciate your patience for the member submission to happen since that is a long winded process. I have received several public requests for HTTP interception in Mozilla Firefox [3]. This may not be a scientific exercise, but serves to indicate public interest beyond Oracle. Given that every browser has long offered a proprietary way to do request interception, it may be appropriate to consider offering a standardized way of doing so. Nikunj http://o-micron.blogspot.com [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0358.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0341.html [3] http://o-micron.blogspot.com/2009/02/overriding-default-http-behavior-in.html#comments
Re: Points of order on this WG
On Sat, 04 Jul 2009 16:03:48 +0200, Maciej Stachowiak wrote: On Jul 4, 2009, at 4:56 AM, Charles McCathieNevile wrote: We are "potentially interested" - i.e. we want to see how the spec comes out first. Given that this is in the scope of existing deliverables, and given taht Oracle are providing the resources to edit it, I see no reason to simply stand in their way. I think a B-Tree style storage API would clearly be in scope of existing deliverables. However, it's not clear to me that Oracles's other proposals (programmable http cache, request interception) are. As I understand it, those technologies don't really relate to storage, or even networking as such, but are meant to serve a role similar to HTML5's Application Cache feature. Also, Nikunj's request was to add these things to the charter, from which I infered the charter doesn't already obviously cover them. As I noted in my earlier message to Nikunj, as far as we (chairs, staff contacts and domain lead) can see the features *do* relate to storage, and are in scope of the charter as is. So it's OK, you don't need to worry about the charter changing. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Points of order on this WG
On Jul 4, 2009, at 4:56 AM, Charles McCathieNevile wrote: On Sat, 27 Jun 2009 03:06:21 +0200, Maciej Stachowiak wrote: On Jun 26, 2009, at 10:51 AM, Nikunj R. Mehta wrote: Secondly, Oracle proposes adding request interception and programmable http cache to the WG's charter. Oracle will provide resources for editing and reviewing proposals for all three deliverables. We already have a broad charter and quite a few deliverables. Before we add more to the charter, I'd like to understand the degree of interest in request interception and programmable http cache. Is anyone besides Oracle interested in pursuing this technology? Are any implementors interested in implementing it? We are "potentially interested" - i.e. we want to see how the spec comes out first. Given that this is in the scope of existing deliverables, and given taht Oracle are providing the resources to edit it, I see no reason to simply stand in their way. If there turns out not to be interst, then it will have a tough time getting to Rec. There are specs people claim to be very interested in, but are not prpared to put ay resources into moving forward - so clearly general surveys of interest are a poor way of understanding reality. I think a B-Tree style storage API would clearly be in scope of existing deliverables. However, it's not clear to me that Oracles's other proposals (programmable http cache, request interception) are. As I understand it, those technologies don't really relate to storage, or even networking as such, but are meant to serve a role similar to HTML5's Application Cache feature. Also, Nikunj's request was to add these things to the charter, from which I infered the charter doesn't already obviously cover them. It's hard for me to evaluate Apple's interest in these technologies without seeing a concrete proposal for these features, so I definitely don't object to a draft. But I don't see justification for changing the charter at this time. Regards, Maciej
Re: Points of order on this WG
On Sat, 27 Jun 2009 03:06:21 +0200, Maciej Stachowiak wrote: On Jun 26, 2009, at 10:51 AM, Nikunj R. Mehta wrote: Secondly, Oracle proposes adding request interception and programmable http cache to the WG's charter. Oracle will provide resources for editing and reviewing proposals for all three deliverables. We already have a broad charter and quite a few deliverables. Before we add more to the charter, I'd like to understand the degree of interest in request interception and programmable http cache. Is anyone besides Oracle interested in pursuing this technology? Are any implementors interested in implementing it? We are "potentially interested" - i.e. we want to see how the spec comes out first. Given that this is in the scope of existing deliverables, and given taht Oracle are providing the resources to edit it, I see no reason to simply stand in their way. If there turns out not to be interst, then it will have a tough time getting to Rec. There are specs people claim to be very interested in, but are not prpared to put ay resources into moving forward - so clearly general surveys of interest are a poor way of understanding reality. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
