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

Received on Wednesday, 1 July 2009 11:32:39 UTC