- From: timeless <timeless@gmail.com>
- Date: Thu, 21 Aug 2008 10:46:22 +0300
- To: "Web Applications Working Group WG" <public-webapps@w3.org>
> COMMENT: Although logically true, I think the intention of the text is > clear enough. ok >> A conforming specification must indicate if any resources >> are mandatory or reserved and what specific function they serve >> in the widget resource. >> Rationale: >> To make it more efficient for widget user agents to locate the resources >> they require at runtime. For example, the packaging format may require >> authors to place all resources inside a 'resources' directory located at the >> root of the widget resource. >> 1:25 PM i don't understand how that justifies the previous bit >> to address the individual > > QUESTION: unsure how to proceed. Can you please reiterate your concerns. i think the problem is that i couldn't understand how/why the rational related to the requirement. if you mean something like: For example, the packaging format may require authors to place all images inside a 'resources' directory located at the root of the widget package to enable widget user agents to precache images. > resolves to something akin to "widget://myWidget/images/bg.png"))." > > QUESTION: does the new example make any more sense? it's slightly better, but i think the scenario should be more like your file is something_localized/file.html and you're trying to reach something_maybe_localized/images/bg.png so you use "/images/bg.png" where / is rooted to the package protocol (e.g. widget:). or perhaps a better thing is you have code which wants to use window.location to dynamically construct ./images/bg.png and in order for this to work, window.location must work.... >>>> To allow the configuration document to be extracted and used by other applications (either on the server or on the client side) for different purposes. >> 4:10 PM the parenthetical bothers me. i might have a widget aggregator which > QUESTION: unsure how to proceed here? The requirement is simply that > other software programs can get at the configuration document and use > it as they please. To allow the configuration document to be extracted by unrelated programs (not necessarily client or server side) and used by other purposes. > COMMENT: Agreed. I think the Working Group were thinking about this > more from a developer or distributor's perspective. A distributor > could set up a Web service that serves the widgets' configuration > documents available on his or her widget repository. The developer > could then build a widget that allows the repository to be browsed, > etc. i think offering the example of a distributor gallery could be included in rationale. > COMMENT/QUESTION: I think I'll leave the comment for now, but if the > issue comes up again I will change it to be more clear. However, if > you *really* think it should be changed, I will change it. i keep reaching the same conclusion as i rewrite/reread.... > COMMENT: Retaining "preferences" as this is the matches the language > we use in the API spec. oh well > COMMENT: Agreed, however, how vendors deal with UI issues is an > implementation detail. I think the requirement is probably clear > enough. ok > COMMENT: yep, it's certainly annoying but I think it again captures > the intention. > COMMENT: agreed. However, I still think the current example is good enough. we'll see how much drain these devices get. i've definitely seen groups who think flashing is a good thing, and i've recently worked with groups who complain that people should know that flashing is a bad thing. i keep reaching the same conclusion. Now I can also point to App Store which uses the same red circle indicator, if you want to suggest a star instead, that's fine ;-). >> timeless.bmo1: A conforming specification must specify the APIs proposed in >> this section in such a way that they are implementable in ECMAScript. > COMMENT: I think the intention of this statement is fairly clear. If > you want to suggest some better text I would be happy to include it. > QUESTION: Can you suggest some better text for R31. ECMAScript Compatibility? the language still doesn't work... i guess just reference WebIDL (actually I discussed this w/ marcos and that was really his idea). > "unparring")." > QUESTION: does that sound ok? it seems in my later full read that i indicated the last word in the block was not ok, "oops" :) but yes, otherwise, it sounds fine :) >> 4:59 PM perhaps you should have a define at the top that says "HTTP" in this >> document means HTTP or HTTPS > COMMENT: addressed by citation. ok > COMMENT: Keeping preferences for now. oh well > COMMENT: agree, not the best example, but it gets the point across I think. ok > COMMENT: I think it is generally assumed within the working group that > a user is at least one of the things or people you listed above. ok.
Received on Thursday, 21 August 2008 07:47:01 UTC