Widget Packaging and configuration LC review

Hello All,
Here are some comments on the Jan 17th draft:



1.5 Global Definitions
There are some misplaced quotes that could be deleted and I propose the more
generic formulation:
The [Widgets-Landscape] defines a widget as an end-user's conceptualization
of an interactive single purpose application for displaying and/or updating
local data or data on the Web, packaged in a way to allow a single download
and installation on a user's machine, mobile phone, or any Internet-enabled
device. Because widgets are packaged, they can be liberally shared by users
without relying on [HTTP] (i.e., users can share widgets over Bluetooth or
through other distribution channels).

In addition with the defined words, we should also add the following:
A User is the actual consumer of the widget content that the author has
created.

A User Agent is the runtime environment in which a widget runs. It is also
known as a widget engine.


6 Widget Resources
In this section ther is a lot of references to ³localized folders² where the
wording should be more specific as it is not just anywhere but at the root
level of the righ local folder, therefore I propose the following edit:

    * One or more start files, located at the root of the widget or in the
root of the language folders.

The formulation has also to be edited in the same way all throughout the
rest of the document. There is a distinction between the localization folder
(ie ³/Locales/²) and the language folder (ie ³/Locales/FR/²)


6.5 Content Localization
Author requirements: According to [BCP47], one should avoid region, script
... (unless there is a good reason to include them) as the a widget user
agent...
The ³a² seems to be a copy/paste edition leftover that should be deleted...

Localized Widget Example
In order to cover tha various aspects, I belive this very good example
should also include the following cases:
* a script.js localization
* a folder structure localization
Therefore I propose to ad the /Locales/en-gb/scripts/engine.js file in this
example with the related comments to explain the cases.

6.7 Custom Icons and Default Icons
An icon must be located either at the root of the widget or in the root of
the language folder.
Same distinction as in section 6

A default icon must be located either at the root of the widget or in the
root of the language folder.
Same distinction as in section 6

Default Icons
In the table order I¹m not sure I understand why the png ad the gifs are not
on top of the list.

6.8 Thumbnail
A thumbnail is an optional file inside the widget resource that graphically
represents the widget in a running state. The thumbnail must be located
either at the root of the widget or in the root of the language folder.
Same distinction as in section 6

7 Configuration Document
Configuration documents can exist either at the root of the widget or in a
the root of the language folder.

Note: Any configuration document not at the root of the widget or not in the
root of the language folder will be treated by the widget user agent as an
arbitrary resource.
Same distinction as in section 6

7.3 Attribute Types
Window mode attribute
    A keyword attribute whose value is one of the following valid window
modes: iconized, minimized, expanded, fullscreen and settings.
I propose the following wording for the various modes: iconized, minimized,
expanded, fullscreen and settings
I would include some kind of attributes to the full screen to allow the
determination of both the screen size (qvga, vga,...) and the screen
orientation (landscape, portrait). I think that it will be usefull to
consider the settings as a mode as it might simplify the way to access to
this important functionality of the widgets.

xml:lang attribute
While reading this element and the spec examlpes found bellow I was
wondering if the lang attribut could be associated with an element could
mean that if you replicate the element a second time with another lang
attribute it would be a way to allow the translation. Although I know the
answer is no, I was wondering if it needed to be detailed in a ³you should
not² type example in the right part of the spec?
You should not find:
<widget xmlns="http://www.w3.org/ns/widgets">
   <name xml:lang="fr">Mon widget</name>
   <name xml:lang="en">My Widget</name>
</widget>

7.10 The access Element
I know we¹ve talked about this already, but while reading the spec once
again, I was wondering if we could use a media type as a way to identify
what plug-in to turn on
<access network="true" plugin="application/x-shockwave-flash"
plugin=²audio/mpeg²/>

7.11 The content Element & 7.14 Window Modes
I wonder if the mode should be available in this element so that you could
define a page or file for each mode.  But if we go through that root we also
need to include a variable element to pass the settings from one mode to the
others... 
As a content provider I think that the mode change should be easier to
adress in an API access then that way, but it¹s a proposition to open the
debate.


7.15 Indicating Text Directionality with <its:span>
The proposed list should define the default to be ltr






And for those that did read this mail util the end :) I want to thank Marcos
for making this a reality and wish everyone of you widget followers a very
good 2009 widget year...
Best Regards, 
Benoit

> 
> Benoit  Suzanne
> Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM
> t. +33 (0)145 298  198 - m. +33 (0)680 287 553
> benoit.suzanne@orange-ftgroup.com
>