Hi, At the last teleconf, it was requested that I prepare a list of P&C work items that could be distributed among those WG members helping with the standardization of widgets. Here are a parts of emails that need responding to (order does not denote priority, though Josh's comments seem to be most substantive.):
On Thu, Jun 18, 2009 at 3:26 PM, timeless<timel...@gmail.com> wrote: > 9:01 AM me: hey, you won't like this, but... I think we botched the > l10n stuff :). The problem is that the design is based on individual > resources, which is wrong. Negotiation should really be done at the > Package level. This is one of those things where thinking HTTPish > screws you over. A user thinks about a web application or widget as a > single resource. That there are multiple subresources isn't > interesting to a user. So the right algorithm is: 1. collect the full > list of all locales for which the package is partially localized. 2. > build the list of user requested locales using the algorithm we > defined. 3. Use the first matching locale between (1) and (2). 4. Deal > with fall back. I think 4 involves telling Authors that if they want > to be able to use a /locales/en/ image in /locales/en-us/ then they > need a /locales/en-us/images.css that pulls in /locales/en/bird.jpg -- > however, it's probably best just not to allow it at all. > http://en.wikipedia.org/wiki/Coccinellidae is something I encountered > @HEL flying to the F2F, I call it a Lady Bug, but the label (embedded > in what I'll call a "picture" said "Lady Bird", and I though it was a > mistake, so i took a "photo" of it to post to my friends. If I posted > the photo as /en/, the GB/AU/... friends would not get it). Similarly, > Nokia has this gem: > http://www.webwizardry.net/~timeless/w7/nokia%20communication%20centre%20-%20Use%20the%20Calendar%20view%20in%20Nokia%20Communication%20Center%20to%20manage%20your%20device%20calendar%20for%20example%20by%20creating%20editing%20or%20deleting%20calendar%20entries.png > which is because they tried to be clever about sharing a picture > between the en-GB installer and the en-US installer. > The results are terribly embarrassing > 9:02 AM Put another way. The goal of localization should be twofold: > 1. allow the user to express a preference. 2. enable the author not to > make the mistakes that Nokia has made > 9:03 AM mixed content such as my Lady Bug/Bird example and Nokia's > myriad examples (the classic one being their Flag example, url > available for archival purposes later; the more modern example being > centre/center). > > On Fri, Jun 12, 2009 at 6:35 PM, Dominique Hazael-Massieux<d...@w3.org> wrote: > There are quite a few aspects that make a zip archive an invalid widget > described in the processing section, but which are not highlighted as > conformance checker requirements, e.g: > * Step 1 labels an archive with a wrong media type as invalid > * Step 2 adds as cause of invalidity "split"-zips, and encrypted-zips > (beyond the already noted requirements on version and compression > method) > * requirements on the configuration file (XML well-formed, vocabulary > constraints) > (and probably more) > On Wed, Jun 17, 2009 at 10:04 AM, Dominique Hazael-Massieux<d...@w3.org> wrote: > Hi, > > I wrote a simple XSLT to extract the conformance requirements from the > Widgets spec [1], with the following output: > http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F% > 2Fdev.w3.org%2F2006%2Fwaf%2Fwidgets%2Ftests% > 2FextractTestAssertions.xsl&xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin% > 2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252Fwidgets% > 252F > > Based on these, here is a review of the Widgets spec based on > conformance requirements analysis: > * ideally, only the classes of products would appear as subjects of the > conformance requirements; e.g. "A folder may contain zero or more file > entries or zero or more folders" would be rephrased as "A valid widget > package may contain folders with zero or more file entries or zero or > more folders"; this would have two benefits: simplify the analysis of > conformance requirements for building test suites, and identify possible > ambiguities as to what is affected when the conformance requirements is > not respected; that said, I don't think it is crucial so feel free to > not go through all the conformance requirements if that's too much work > * similarly, conformance requirements that use the passive voice are > suspect (since they often don't tell to which class they apply) > * "For sniffing the content type of images formats, a user agents must > use the rule for Identifying the media type of an image" -> this assumes > that the user agent already knows the file it is sniffing is an image; > if that's true, the text should make it clear why, and if not, it should > probably be reworded to say that a user agent must sniff for images > format first > 1. http://dev.w3.org/2006/waf/widgets/tests/extractTestAssertions.xsl > > > > 2009/6/22 Krzysztof Maczyqski <198...@gmail.com>: >> other compression formats will cause the widget package to be treated as an >> invalid Zip archive. > In the context of definitions present in the document this would effectively > render the OPTIONAL (so says 3.1) support for other compression formats > useless. As an authoring guideline, this text isn't normative, so if included > in the final spec, should be considered false. Of course false statements are > to be avoided. > >> If a CC encounters a compression method that is not one of the valid >> compression methods,then the CC must inform the author that the Zip archive >> is an invalid Zip archive. > This, on the other hand, is normative. So the problem is serious. I suggest > lowering this to a warning by CC that user agents will be allowed to treat > the Zip archive as invalid. > >> If the widget package does not contain a start file, or the start file is >> not one that is supported by a particular user agent, then the CC must >> inform the author. > How can a CC have knowledge of all user agents? Or do you mean a CC is a user > agent (indeed, in general terminology, but this term has been narrowed for > this spec in 2)? > -- Need to check all CC requirements. A lot of them assume applicability to a user agent. Raised by Dom as well. Another Option is that we drop all CC requirements from this spec and move them to a new spec. >> If the file pointed to by the src attribute is of a vector graphic format, >> then this value must be used. > Why? Vector formats may include preferred sizes specified. Even if not, some > environments require specific sizes and it should be assumed that whatever > else is specified, will be scaled. In case of vector graphics without > intrinsic dimensions I believe it's the environment's responsibility to apply > a reasonable default. > >> The its:dir attribute and the its:span element may each be used as a child > What data model are you using to call attributes children? > >> such as "en-us", "en-gb", and so on > Canonical spelling is "en-US", "en-GB", and so on. Do you intend to require > deviating from it? >> However, widget packages localized at any folder level (e.g. "locales/zh/") >> needs to be fully functional as a localized widget. That is, authors cannot >> simply put shared files into a language level folder, but need to put all >> files needed into the language level folder for the widget to work (for >> example, having "a.gif" in both the "/locales/zh-Hans/" folder and >> "/locales/zh/"). > The "Fallback Behavior Example" in 8.4 suggests otherwise. Could you clarify > this issue in the spec, please? > >> The steps for processing a widget package involves nine steps that a user >> agent SHOULD follow > Why not just MAY, given the next paragraph? >> Each item in the unprocessed locales must be a string shorter than eight >> characters, in lowercase form > I find both of these requirements objectionable. "x-klingon" is 9 characters, > country subtags are canonically upper-case and script subtags mixed-case. > >> This is in error and the user agent must ignore it. > Although in principle naming things arbitrarily doesn't change meaning, it's > somewhat difficult to accept that comments are proclaimed to be "in error". > >> Once all the elements in the elements list have been processed, go to Step 8. > Overzealous implementation would then perform Step 8 twice, since it's been > already instructed before to perform all 9 steps in sequence. > > On Mon, Jun 19, 2009 at 3:19 PM, Kai Hendry<hen...@iki.fi> wrote: > http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F%2Fdev.w3.org%2F2006%2Fwaf%2Fwidgets%2Ftests%2FextractTestAssertions.xsl&xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252Fwidgets%252F > > > After staring at: """ > As there is no notion of a media type within Zip (i.e., no > content-type metadata, as described in the [HTML5] specification), a > user agent must perform file-extension to media-type mapping, followed > by content-type sniffing, in order to determine the media type of a > file. > > For sniffing the content type of images formats, a user agents must > use the rule for Identifying the media type of an image. For other > file formats, a user agent must use the rule for Identifying the media > type of a file. """ > > > I was thinking why you don't just collapse "rule for identifying the > media type of an image" and "Rule for Identifying the media type of a > file" into one section. The rules are the same, aren't they? Check > ext, else sniff. > > > Not sure how I am supposed to test this. Save a PNG as a index.txt and > the test parses when the output is garbled? i.e. it wasn't sniffed. > On Mon, Jun 19, 2009 at 4:03 PM, Kai Hendry<hen...@iki.fi> wrote: > """A custom start file is a start file identified via a content > elements src attribute. The custom start file must be a processable > file inside the widget package, determined by applying the rule for > identifying the media type of a file. When a start file is > not explicitly declared via the content element, then start file will > be one of the default start files.""" > > > So if <content src="doesnotexist.html"/> and doesnotexist.html is not > in the widget, is it treated as a Invalid Zip? Or Invalid Widget? I > find it a little confusing how you imply a > http://dev.w3.org/2006/waf/widgets/#invalid-widgets invalid widget is > an invalid Zip file. A Zip file archive might be fine, except for a > poorly written config.xml. For the sake of simplicity I guess it's OK. > > I think this doesnotexist.html case _might_ be dealt with step3 of > http://dev.w3.org/2006/waf/widgets/#step-7--process-the-configuration-docume > in the Content element: > "If path is a valid path". Does "valid path" mean "file exists"? > > > > btw "type=" from http://dev.w3.org/2006/waf/widgets/#content is not > considered in your "rule for Identifying the media type". What > happens when a PNG is renamed index.html with a type image/gif? > <content type="index.html" type="image/gif /> > -- Marcos Caceres http://datadriven.com.au
