Re: Widget Packaging and configuration LC review

Hi Benoit, 
Inline comments below. For the sake of the LC disposition of comments,
please be sure to indicate if you are satisfied with the changes I have
made....   

On 1/20/09 8:50 PM, "SUZANNE Benoit RD-SIRP-ISS"
<benoit.suzanne@orange-ftgroup.com> wrote:

> 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).
> 

Fixed. 
 
> 
> 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.

Added, but as "end-user" as that is the term that is used throughout the
spec.  
 
> A User Agent is the runtime environment in which a widget runs. It is also
> known as a widget engine.

That definition of user agent is not broad enough to encompass conformance
checkers. The definition you suggested is already covered by "widget user
agent". 

> 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.

I know that "localized folder" seems weird there because "localized folder"
has not yet been defined when you get to that part of the document. I've
added "root of the".

> 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/²)

The "locales/" is defined as the "container for localized content" (there
was a mistake in the definition). However, I would prefer not to change
this. 

Instead, I've tighten up the definition of both localized folder and the
container for localized content and added examples. Can you please check if
it is more clear now.
 
> 
> 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...

Fixed. 
 
> 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.

I made your suggested change to /en-au/.
 
> 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

fixed
 
> 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

Fixed 
 
> 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.

The reason that the table is structured that way is that the optional types
are deemed to be more powerful then the required types: if the user agent
supports SVG, which could be an interactive animated icon, it will select
SVG first (rather then png or gif), and so on. PNG is also considered better
than GIF, so it is selected before gif.
 
> 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

fixed.  

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

Fixed. 

> 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.

Fixed. 

> 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.

I think CSS media queries might cover this. Currently investigating. Please
see the recent emails from Mark and Arve regarding this topic and please
raise your concerns there.
 
> 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>

Added the example and rationale why the above does not work. Please check
that it is ok. 
 
> 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²/>

Media types are usually associated with content. Seems a bit strange to
define things in this way. Also, some engines might natively support, for
example, flash without requiring a plugin.

My proposal is that we drop the "plugin" attribute all together. Instead, if
the engine needs to defer to a plugin, then it should do so based on the
type identified by the content element.

<widget xmlns="http://www.w3.org/ns/widgets">

 <content src="maps.swf" type="application/x-shockwave-flash">
   <content src="maps.hml" />
 </content>
 
</widget>


> 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.

I've also raised this issue earlier (wrt having different views of the same
content). This needs further discussion, but not here. Again, please respond
to Mark and Arve's recent thread on the matter.
 
> 7.15 Indicating Text Directionality with <its:span>
> The proposed list should define the default to be ltr

Unicode characters have an inherent directionality so making ltr explicit
does not make sense here (i.e., Latin chars are always ltr, but if we made
lrt default, then Hebrew would go the wrong way!). ITS helps when you want
to mix languages and override the default behavior of the Unicode bidi
algorithm.  

> 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...

Thanks Benoit!:D

Kind regards,
Marcos

Received on Wednesday, 21 January 2009 10:50:26 UTC