- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Wed, 1 Jul 2009 14:02:59 +0200
- To: "marcosc@opera.com" <marcosc@opera.com>
- CC: public-webapps WG <public-webapps@w3.org>
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