RE: [widgets] P&C comments, 8

Regarding 6.6 & Step7:
Thanks. Ok.

Regarding 7.12
>>Agreed. What do you think of the text above?
Thanks, I am ok with the text.

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Wednesday, July 01, 2009 1:23 PM
To: Marcin Hanclik
Cc: public-webapps WG
Subject: Re: [widgets] P&C comments, 8

On Mon, Jun 29, 2009 at 2:10 PM, Marcin
Hanclik<Marcin.Hanclik@access-company.com> wrote:
> Hi Marcos, All,
>
> These are a few editorial comments to the latest P&C ED.
>
> 6.6 Icons and 9.1/Step7/<icon>
>
> Step7 requires only a valid path for src attribute:
> "Let path be the result of applying the rule for getting a single attribute value to the src attribute. If path is not a valid path, then the user agent must ignore this element and its attributes. Proceed to the next element in the elements list."
>  whereas 6.6 is more restrictive and says:
> " An icon must be located either at the root of the widget package or at the root of a locale folder."

I've removed (as part of Kai's comments, who noted the same issue):
"An icon must be located either at the root of the widget package or
at the root of a locale folder."

I've redefined the definitions:
"A custom icon can be located either at the root of the widget
package, or at the root of a locale folder, or in an arbitrary
folder."

"A default icon must be located either at the root of the widget
package or at the root of a locale folder."

> Therefore I suggest to refer to 6.6 from Step7 is some way, e.g. by creating a new rule for icon path or by just adding some prose in Step7, like:
> "Let path be the result of applying the rule for getting a single attribute value to the src attribute. If path is not a valid path or does not fulfill the restriction from 6.6, then the user agent must ignore this element and its attributes. Proceed to the next element in the elements list."
>

6.6.1 basically now says that an custom icon can appear anywhere, so I
think what is there is now fine.

> 7.12 Note
> "A user agent can expose a feature through, for example, an API, in which case a user agent that supports the [Widgets-APIs] specification can allow authors to check if a feature loaded via the hasFeature() method." (Non-normative)
> [Widgets-APIs] spec says nothing about loading features, at least now.

True. I removed the note but reused some of the text in the actual
element definition:

"A feature is a runtime component (e.g. an Application Programming
Interface or video decoder) that is not part of the specified set
provided by the Widgets 1.0 family of specifications. The feature
element serves as a standardized means to request the binding of an
(URI) identifiable runtime component to a widget for use at runtime.
Using a feature element denotes that, at runtime, a widget may attempt
to access the feature identified by the feature element's name
attribute. How a user agent makes use of features depends on the user
agent's security policy, hence activation and authorization
requirements for features are beyond the scope of this specification.
"


> It seems not to be agreed that hasFeature() method would be used for that purpose,
> specifically because hasFeature() is used in DOM to check for - static IMHO - existence of some module/functionality/feature, and feature loading that is meant within P&C is of dynamic nature.
>

hasFeature was dropped at the F2F.

> So I suggest removing that sentence from the note in order not to create a de-facto standard.

Agreed. What do you think of the text above?

--
Marcos Caceres
http://datadriven.com.au


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Wednesday, 1 July 2009 12:07:49 UTC