[widgets] P&C, outstanding feedbac...

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<timeless@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<dom@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<dom@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 <1981km@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<hendry@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<hendry@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

Received on Thursday, 2 July 2009 12:19:43 UTC