Disposition of comments for the Web Applications Working Group

Dear WG,

I have written my comments below.

Please take into account the difference between IRI and IRI reference defined in RFC 3987.
Should there be a requirement (probably only may or should for the first version) to specify some way of exposing custom APIs on instances of a widget (like XBL bindings do)?

> email checkers
s/email/E-mail
> This document does not address the requirements of "web widgets", such as iGoogle Gadgets or Windows Live Gadgets.
Why not? Aren't they similar enough to be covered by one set of specs and one requirements document (perhaps with a bit of inline tailoring)?
> A conforming specification is one
Not necessarily, since you plan to have 4. Should it be called conforming set of specifications?
> a widget resource should be easy for authors to create without requiring special software
This is why ZIP (or whatever ends up decided upon) compression should be optional (also see below). Furthermore, I don't envision taking advantage of the Security design goal by a typical author when creating widgets without special software.
> R1. Packaging Format
There are arguments for enabling compression, and ZIP is discussed on the list. I'm in favour of it as long as it's optional, i.e. there can also be uncompressed widget resources. R10 satisfies this, but uniformity between these two forms should be maximized. Is Store method of ZIP considered? It fails the previous quote. MIME features (Content-Transfer-Encoding comes to mind) then?
> R2. File Extension
It seems contrary to AWWW (see also "Cool URIs don't change" by Tim Berners-Lee). Also, how Device independence design goal is interpreted to support this? I see no hardship for supporting MIME types on various devices instead of sniffing (or mapping, if it's defined for a file system by design) them by file name extensions.
> In addition, the packaging format should allow authors to add and remove resources of a widget resource without needing to recreate the widget resource.
Leverage MIME multipart and Content-Location, please. Motivation: Compatibility with other standards.
> The addressing scheme must not expose the underlying file system
Please add "(if any)" after that.
> must not be able to address resources outside the widget resource via the addressing scheme
Such ability may be useful (in some future version or even in this one), although I can see the concerns. But it seems harmless, for example, to use URNs (with semantics handled by widget user agent, such as accessing the default instance (forms in older versions of VB have those) or some operating environment motives and artifacts - these are "outside the widget resource", right?). I presume there will be places where IRIs unconstrained by this addressing scheme can be used to allow such usage. Still, I think this must not cannot be enforced syntactically without disallowing relative IRI references (and I can see no reason for disallowing them). Another issue with this is that other instances of the same widget are themselves "resources outside the widget resource" (but not widget resources). Even though R5 currently only provides for addressing resources contained in the widget resource associated withj a given instance of the widget, I believe the goal is (or should be) to enable addressing the instances themselves as well. I would therefore suggest the wording given below for the entire paragraph. Also please clarify that "addressing scheme" means some recipe for minting URIs, not necessarily a URI scheme (which may or may not result from ongoing discussion as the best solution).
--
A conforming specification must specify an addressing scheme (a new URI scheme or some prescribed use of an existing one) which must or should be used to address at runtime the individual resources within the widget resource in association with the current or another instance of the widget, as well as these instances themselves. This does not preclude allowing use of arbitrary IRI references in some contexts defined by a conforming specification. When the addressing scheme is used, the widget user agent must be required not to expose any other resources to the widget instance. For this purpose a conforming specification may require that accessing resources identified by IRIs using the addressing scheme which leave the allowed space described above must fail. If addressing resources outside the allowed set described above is possible with the addressing scheme, determining that this is the case for a given IRI reference should be easy for the author, at least for absolute IRI references. The addressing scheme should be one that web authors would feel comfortable using or are already accustomed to.
--
Some specific caveats can be mentioned in the rationale extended thus:
--
To disable access by widget instancs to the underlying file system (if any) or other resources which are not instances of the same widget or resources contained in the widget resource used to create the current set of widget instances.
--
> how resources need be structured
Insert "to".
> R9. Device Independence
Please rename to "Device independent delivery" or something. "Device andependence" is already a design goal.
> where by only widgets that meet a particular level of quality
s/where by/whereby
> A conforming specification must recommend that a conforming widget resource be sent over HTTP with a formally registered MIME Type.
It must be assigned the right MIME type. HTTP has nothing to do with that. Please also consider that it's the MIME type that tells the user agent it's a widget. Changing the MIME type requires different semantics pf processing the resource, even if the representation remains the same (see http://www.w3.org/2001/tag/doc/mime-respect). With text/plain it's not a widget anymore (so out of scope for this spec) but a body of plain text.
> A conforming specification must specify the structure and semantics of elements
Are those XML elements?
> The metadata must be extractable, processable and reusable in other contexts
Informative reference to GRDDL in the spec would satisfy this.
> To provide authors with a practical set of metadata elements
I believe that metadata should be extensible, so a generic hook should be included in addition to some required items.
> R14. Authorship and Widget Metadata
Almost all mentioned items seem optional.
> an author's name, email, and organization
s/email/E-mail address (Should it be mailbox (RFC 2822) or mailto IRI?)
> a unique identifier
How to check for uniqueness? What if a widget user agent encounters a widget with a non-unique identifier?
> as well as a model for how this data must be processed by a widget user agent
What's the point of this? The user will in all realistic scenarios be able to edit the widget resource manually to prevent such processing, so if the intent is to enforce some obstacles, it's futile.
> R16. Visual Rendering Dimensions
This is privileging visual media. This is making an architectural assumption about widgets that a presentational aspect (intrinsic dimensions) is part of their nature (nothing wrong with this, SVG and MathML do the same, but just calling for awareness), so not deferring it to styling as the only option is acceptable. Please clarify however that if styling is applied, it takes precedence. The same with other means of redefining the dimensions a posteriori. And make them optional (ideally independently in each dimension) to allow widgets without intrinsic width or height.
> mechanism that addresses the start file
A remnant of some old very file-centric
draft. Please change to resource.
> it may be able to address a resource on the Web over HTTP
Why not other protocols or schemes? To disable access to local resources? I believe this distinction should be defined in a more general way and probably ultimately defer to widget user agent policy.
> or resources that are of media types supported by a widget user agent
If a bootstrap resource is of an unsupported media type, it's useless in this context. On the other hand, any can be supported by a given agent.
> so long as they are compatible with the widget user agent
This term will have to be defined in the spec. But I doubt the definition will be very meaningful and not a moot paragraph.
> may specify an automated model
Combined with the previous requirement this means that a spec just may define something that it must require the agent to do. Not that it couldn't possibly make sense, but if it does for some reason, please state it.
> an automated model for finding the start file
Again a file?
> For example, the conforming specification could specify a model that searches for a default file name (index.htm, index.html, index.svg, etc)
Please don't rely on extensions.
> the widget user agent could try finding files
At this point I can see clearly that entirely avoiding talking about files seems unrealistic. Let's broaden the term then. I suggest replacing "(or similar logical containers)" in R3 with "(understood in this document in a broader sense than in some popular file systems, namely as forms of generic logical containers)".
> A conforming specification must specify the default values for parameters
I wrote about this above already. I'd like this to be changed so that for some predefined parameters the agent must supply the values (possibly obeying some rules set forth by the spec) if they are missing. And sometimes even overriding provided ones (like visual dimensions) should be allowed.
> can be used independently of the widget resource that contains it
This jeopardizes addressability when R5 is taken into account. Only an issue if running a widget with an externally associated configuration document is an issue. Or does it implicitly say that the ability to independently use other contained resources is not required?
> 4.3 Scripting Interfaces
Possible styling issue in the spec.
> compatibility with other standards
In R25 and R26 this is surprising but very interesting. Can you mention any W3C (or equivalent) standards which you intend to leverage?
> A conforming specification must define a set of states in the lifecycle of the instantiated widget that are able to be captured through script.
I suggest: "A conforming specification must define a set of states and transitions in the lifecycle of the instantiated widget. The transitions must have associated events which can be consumed by event handlers, such as scripts. Additionally the API must expose the current state.".
> if the widget resource is connected to the network
s/resource/instance
> (or any of its windows)
s/windows/presentation contexts (Also add Accessibility to motivation here (and possibly in some other places, such as R37. It's the only unused design goal.)
> operating system services
s/system/environment
> For example, when a news widget receives a news item about a particular company, it could tell a stock widget stock quotes widget to display any changes in that company's share price.
Now I'm really surprised. The use case is perfectly reasonable, but what about addressability? Isn't it assumed elsewhere that only instances of the same widget can be addressed with the special scheme?
> A conforming specification SHOULD specify a means that allows authors to open URLs
How about IRIs?
> The declared interface may also be accessible to screen readers
At least should, I suggest. Also see the rationale.
> persistently store user preferences for each instantiated widget.
Instances are ephemeral by nature. Next run of the same widget resource yields another instantiated widget. Where's the persistence? Shouldn't the word "instantated" be omitted?

Hi,
I'm a member of wai-pf and wcag, and met some of you at the web apps face to face in redmond recently. I was reading through the widgets 1.0 requirements spec, and came across this accessibility requirement. Wondering why only should and may here, and not must?

R37. Language Accessibility

A conforming specification must specify that the language used to declare the user interface of a widget be either HTML<http://www.w3.org/TR/widgets-reqs/#html> or a language that is accessible at various levels: it should provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through an non-graphical UI. The declared interface may also be accessible to screen readers, allowing relevant sections of text and functionality to be accessed by non-visual means.

Also, I noticed references to google and yahoo web gadgets documentation, and wondered if you'd seen the Windows Live Gadgets SDK [1]?

Thanks,
Cynthia
[1] http://dev.live.com/gadgets/sdk/docs/resources.htm

Below is a review that Josh Soref (Timeless) did of the Widgets
Requirements LC. The review was conducted using gMail's chat
yesterday. I've marked where I've made editorial changes.

Josh raised two significant issue which requires discussion from the WG:

ISSUE 1: should we mandate that developers and admins be allowed to
install their own certs? (R38. Additional Digital Certificates)
ISSUE 2: Widgets (not just widget engines) should be able to specify
which proxies they communicate through.

Josh, I've responded by marking sections as:

TYPO: fixed a typo. You can ignore all these.

EDITORIAL: made an editorial change as you suggested.
Please indicate if you _not_ satisfied with any of these.

COMMENT: either a disagreement with suggested change or an
explanation of why a something was addressed in
some particular way

QUESTION: anything I was unable to understand or
need further guidance on.

On Wed, Jun 25, 2008 at 12:44 PM, timeless.bmo1@gmail.com
<timeless.bmo1@gmail.com> wrote:
> 12:49 PM me: http://dev.w3.org/2006/waf/widgets-reqs/
> timeless.bmo1: Widgets are ... for displaying and updating remote data
> i can't have a widget that's a clock?
> 12:55 PM anyway, the next sentence contradicts the line i quoted
> Typical examples of widgets include clocks
> me: Re: clock widget, would "widgets are ... for displaying and/or updating
> remote data" ? or just "widgets are ... for displaying or updating remote
> data"
> 12:56 PM timeless.bmo1: neither help
> since a clock has 0 remote data
> Typical examples of widgets include ..., games, and those that make use of
> Web services
> "those" doesn't backreference properly
> 12:57 PM me: hmmm...
> "and widgets that" ?
> 12:58 PM "and widgets that make use of Web services, ..." can work
> timeless.bmo1: seems ok

EDITORIAL: changed "those" --> widgets

> A widget is an interactive single purpose application
> clocks may not be interactive
> note that the introduction sentence is better than the earlier one
> 12:59 PM might want to sync them :)

> A widget may run as a stand alone
> stand-alone ?

TYPO: Fixed.

> timeless.bmo1: the runtime environment on which
> in which

TYPO: Fixed.

> timeless.bmo1: As argued by the Widget Landscape
> argued? scary
> 1:01 PM there is currently no formally standardized way to author, package,
> digitally sign and internationalize a widget resource for distribution and
> deployment on the Web
> me: Well, we don't have definitive proof.
> so "argued" seemed like the right word
> timeless.bmo1: i think you want 'or' instead of 'and' before
> internationalize
> but i'm not certain

TYPO: and --> or

> 1:04 PM is as interoperable as possible with existing market-leading user
> agents (known also as widget engines) and existing Web browsers.
> are market-following user agents not known as widget engines?
>
> timeless.bmo1: note that "known also as" is poor, it's better to write
> "also known as"

EDITORIAL: removed "(known also as widget engines)"

> 1:05 PM To be clear, this specification describes the requirements for
> installable/desktop-style widgets (akin to Dashboard, Opera Widgets, and
> Yahoo!'s Konfabulator Widgets). This document does not address the
> requirements of "web widgets", such as iGoogle Gadgets or Windows Live
> Gadgets.
> i'm not sure that helped me at all
>
> timeless.bmo1: i don't suppose you could footnote links to references or
> examples of those features?

EDITORIAL: Added hyperlinks to information about each product.

> timeless.bmo1: should not,recommended
> space after comma, please :)

TYPO: fixed.

> 1:07 PM timeless.bmo1: Note, however, that not all requirements may be
> addressed by those specifications, particularly requirements marked with the
> key word may.
> negatives, all, precedence => mess
> timeless.bmo1: you may want to use 'some' instead of 'all', or just rewrite
> the whole thing

EDITORIAL: section rewritten as "Note: Only normative statements
marked with the keywords MUST and should are required to be
standardized by the Widgets 1.0 family of specifications."

> 1:08 PM A conforming specification is one that addresses all the
> requirements (particularly those that contain the words "must" or "must
> not") listed in this document.
> if you're generating 5 specifications
> and none of them satisfy all of the requirements, but taken together they
> do
> then you have 5 non conforming specifications according to that
> even though the real goal is accomplished :)

COMMENT: Although logically true, I think the intention of the text is
clear enough.

> timeless.bmo1: i think things that aren't addressed need to be highlighted
> with a reference as to why they're being ignored
> 1:10 PM me: I think they should probably just be removed from the final doc
> 1:11 PM timeless.bmo1: it's probably ok for them to be absent from the
> document, but there should probably be a clear and easily findable
> explanation for why something isn't there
> 1:12 PM we get all sorts of strange requests on irc.mozilla.org
> "why can't i do X"
> yes it's true we explain how A-W work
> but sometimes it'd help if we explain why X just isn't there
> me: I see what you mean
> 1:13 PM a compendium document "Informative Notes about unaddressed
> recommendations" would probably work
> that enables it not to be part of the primary deliverable but leaves it
> easily linkable etc

EDITORIAL: Added the text "The Working Group will publish an
informative Working Group Note at the end of the standardization
process listing any requirements that were not formally addressed by
the Widgets 1.0 family of specifications."

> timeless.bmo1: doesn't look like things are required to be easy to
> implement
> 1:15 PM (and yes, i know the group probably has more active implementers
> than it has active consumers, but still)
> A conforming specification needs to support relevant internationalization
> and localization guidelines, as well as consider current practical
> internationalization solutions used by the widget development community.
> this doesn't seem to indicate that it has to enable internationalization
> 1:16 PM i read it as saying that language letter codes could be imported
> from a guideline
> but the spec could choose not to support localization

EDITORIAL: Changed
"A conforming specification needs to support relevant
internationalization and localization guidelines"
-->
"A conforming specification needs to implement relevant
internationalization and localization guidelines"

COMMENT: The widget packaging spec already implements aspects of BP47
for i18n and attempts to conform to XML i18n best practices
[http://www.w3.org/TR/xml-i18n-bp/]. The i18n core WG has been
assisting us with this.

> 1:17 PM A conforming specification needs to be specified in such a way that
> it ensures that a widget resource can still be processed well into the
> future (e.g. 100 years from date of the a specification reaching
> "Recommendation Status" W3C Process).
> 100 years is nice. is that a standard thing?
> because in practice, none of my phones will last that long
> timeless.bmo1: and all of the browsers will have obsoleted everything
> timeless.bmo1: A conforming specification needs to address the security
> concerns of end-users and vendors by recommending appropriate security
> policies and programming behavior. A conforming specification must also
> consider the distribution and deployment security requirements as they
> relate to authors and vendors.
> vendors to me here are user agent authors and not web application hosts,
> and certainly not random devices on the internet. we need to protect all of
> them

EDITORIAL: The section now reads "A conforming specification needs to
address the security concerns of end-users, authors, distributors and
device manufacturers by recommending appropriate security policies and
programming behavior."

> 1:19 PM 4. Requirements
> doesn't say 'normative' or 'informative' unlike the previous n sections

EDITORIAL: added "This section is normative."

> 1:20 PM R2. File Extension
> 1:21 PM doesn't seem to say that a requirement should attempt to register a
> mime type
> (yes, it's almost implied, but..)

EDITORIAL: I've moved Requirement 12 "MIME Type" and made it
Requirement 2. This way, the reader won't wonder about how the MIME
type relates to the file extension.

> 1:22 PM "Note also that"
> i'm not a fan of that.. I'd normally write "Also note" or something...
> Note also ... Web servers may also
> ETOOMANYALSOS

EDITORIAL: text was rewritten: "Also note, in some cases, Web servers
may rely on a file extension to correctly set a widget resource's MIME
type in the HTTP headers."

> 1:23 PM A conforming specification must specify graceful error
> handling/recovery procedures if those resources are used erroneously or are
> missing.
> 1:24 PM some of the error handling you've specified in the other document
> isn't graceful, it's forceful hard failure.

COMMENT: True. I've relaxed this to a 'should': "...specification
SHOULD specify graceful error..."

> To make it more efficient for widget user agents to locate the resources
> they require at runtime. For example, the packaging format may require
> authors to place all resources inside a 'resources' directory located at the
> root of the widget resource.
> 1:25 PM i don't understand how that justifies the previous bit
> to address the individual

QUESTION: unsure how to proceed. Can you please reiterate your concerns.

> drop 'the'

TYPO: deleted "the".

> 1:26 PM or are already accustomed to.
> ends in a preposition. "to which they are already accustomed" is proper
> English.

EDITORIAL: text now reads: "The addressing scheme should be one that
web authors would feel comfortable using or to which they are already
accustomed."

> 1:27 PM addressing a resource via an IRI (e.g. new
> Image('../images/pane.png')).
> i don't think your example helps
> you don't need a special protocol to enable relative paths to work

EDITORIAL: Rewrote Rationale "To allow resources to be resolved and
normalized within DOM attributes. To make it easy for authors to
address and load resources into their instantiated widgets, either
declaratively or programmatically. For example, addressing a resource
via an IRI (e.g. <img src="images/bg.png'/> where the src attribute
resolves to something akin to "widget://myWidget/images/bg.png"))."

QUESTION: does the new example make any more sense?

> 1:29 PM complete with error handling, the reduces
> "the reduces" is wrong here. the natural fix is "this reduces" but i think
> you want to rewrite the sentence to use "to reduce"

EDITORIAL: sentence now uses "to reduce"

> 1:30 PM A conforming specification must recommend a packaging format that is
> suitable for delivery onto many devices, particularly Web-enabled mobile
> devices.
> delivery to

TYPO: onto --> to

> 1:46 PM timeless.bmo1: including it's title
> /its/

TYPO: fixed.

> 1:48 PM that represent metadata about the widget
> probably a widget

TYPO: the --> a.

> reusable in other contexts (for instance, to create an online gallery
> 1:49 PM i'd write showcase. galleries are assumed to be image galleries

COMMENT: Although I agree, I'm keeping gallery as extracting the
<thumbnail> element from widgets can be used for creating an image
gallery.

> 3:47 PM timeless.bmo1: However it may be able to address a resource on the
> Web over HTTP but only of the MIME types allowed by the automated bootstrap
> requirement (below) or resources that are of media types supported by a
> widget user agent.
> 3:48 PM , after However; what about HTTPS?

TYPO: added ",".

EDITORIAL: I've added "HTTP Over TLS. E. Rescorla. May 2000.
http://www.ietf.org/rfc/rfc2818.txt" as a <dd> of [HTTP] in the
references section.

> declared by an author, then automated bootstrapping must occur as describe
> described

TYPO: fixed.

> 3:49 PM (eg '/ui/clock.svg').
> "e.g.,"

TYPO: fixed.

> 3:51 PM The widget user agent should be allowed to select its preferred
> format for the start file, then it should
> file, and then ...
> (index.htm, index.html, index.svg, etc)
> etc.

TYPO: fixed.

> 3:52 PM firstly within localized directory names, as required by automatic
> localization, within the directories of the widget resource.
> automatic localization, and then within

TYPO: added "and then".

> starting form the root directory.
> 3:53 PM "from"

TYPO: fixed.

> 3:54 PM The conforming specification should not ... SHOULD provide
> alternative text representations of an icon where possible
> should "should not" be uppercase?

TYPO: fixed.

> timeless.bmo1: the SHOULD part is wrong
> it should provide for support for
> not should provide

TYPO: added "it"

> timeless.bmo1: To provide authors with a visual means of representing
> widget
> widget_s_

TYPO: fixed.

> For example, an a small graphic
> /as/ a small ?
> hrm, no
> 3:57 PM For example, an a small graphic of a calendar may represent a
> calendar widget.
> For example, -- a small graphic of a calendar may represent a calendar
> widget.
> just remove 'an'

TYPO: fixed.

> A conforming specification must specify a means to declare values of
> either custom or predefined configuration parameters,
> 3:58 PM 'or' doesn't mean what you want
> timeless.bmo1: it basically means the spec could specify A. the spec could
> specify B. the spec does not have to specify A and B
> you want 'and' :)
> 3:59 PM which would be applied as a widget is instantiated.

TYPO: fixed.

> timeless.bmo1: instead of 'a widget' probably want 'each widget', however i
> think you need 'all of which'
> otherwise you're only saying that 1 value might be....

EDITORIAL: added "all of which"

> 4:00 PM A conforming specification must specify the default values for
> parameters in case a parameter is missing or the value supplied by the
> author is invalid.
> needs to be limited to spec defined parameters
> defining default values for author fields doesn't make sense :)

EDITORIAL: Changed it to "A conforming specification MUST specify the
default values for specification defined parameters in case a
parameter is missing or the value supplied by the author is invalid."

> timeless.bmo1: the author might declare that the value for the parameter
> 'width = "50"', or in its absence, the widget user agent will automatically
> set the width to "300".
> i think you've over quoted width = "50", i.e. lose the single quotes
> 4:02 PM it's possible you really want it fully quoted
> in which case the sentence needs a rework
> me: given that it's just an example, it's probably ok to drop the "50" and
> just have width = 50
> 4:03 PM timeless.bmo1: the author might declare '...' indicating the 50 as
> the value for width, or in its ...

EDITORIAL: changed text to "<code>width = 50</code> indicating the
<code>50</code> as the value for width"

> timeless.bmo1: To declare the security intentions of the widget, allowing
> the widget user agent to respond accordingly by adjusting its security
> policies and warning the end-user.
> "respond" is problematic
> it's a static proposal
> 4:05 PM me: allowing the widget user agent to adjust its security
> policies... ?
> 4:06 PM timeless.bmo1: allowing WUA to e.g., confirm with the user before
> installing the W, or adjust its policies before instantiating it.

EDITORIAL: Rewrote to "To declare the security intentions of the
widget, allowing the widget user agent to, for example, confirm with
the user before installing the widget, or adjust its policies before
instantiating it."

> R22. XML, Micro-Syntaxes and Schema
> is the 's' in syntaxes supposed to be in uppoercase?
> timeless.bmo1: lose the shift ;-)

TYPO: fixed.

> 4:08 PM timeless.bmo1: and XML parsers generally have reasonable support for
> Unicode and other character encodings
> other ??

EDITORIAL: dropped "and other character encodings".

> 4:09 PM To allow the configuration document to be extracted and used by
> other applications (either on the server or on the client side) for
> different purposes.
> different => unrelated

EDITORIAL: changed different => unrelated

> 4:10 PM the parenthetical bothers me. i might have a widget aggregator which
> parses things. e.g. http://www.gronmayer.com/it/
> gronmayer is neither a dpkg-ua, nor a dpkg-server
> 4:11 PM well, as long as we define dpkg-ua as something that runs on the end
> user's device ... it presumably uses dpkg, but it doesn't have to. e.g.
> timeless.justdave.net/mxr-test/chinook barely uses dpkg and doesn't need to
> (it could bypass it entirely and i'm fairly tempted at times).
> 4:12 PM The independent configuration document may then be used, for
> instance, for checking information about the widget without needing to
> download the complete widget resource.
> timeless.bmo1: the example is bad. since the file is naturally only
> available in the archive which would require downloading it
> one requirement is that you don't have to parse all files in the entire
> archive

QUESTION: unsure how to proceed here? The requirement is simply that
other software programs can get at the configuration document and use
it as they please.

> 4:13 PM and the other is so that you could cache and store just this file
> for use, w/o retaining the whole archive
> (neither gronmayer nor my server retain the originals)
> hrm. ok, the problem isn't quite what i described
> it's that the English text didn't work :)
> 4:14 PM "The independent" didn't backreference correctly
> change it to "The extracted"

EDITORIAL: changed independent -> extracted

> 4:15 PM timeless.bmo1: but it's still problematic, since widget uas have no
> reason to manually read the file outside an archive

COMMENT: Agreed. I think the Working Group were thinking about this
more from a developer or distributor's perspective. A distributor
could set up a Web service that serves the widgets' configuration
documents available on his or her widget repository. The developer
could then build a widget that allows the repository to be browsed,
etc.

> you really would almost need to have some way to tell a wua that it needs
> to be able to read a standalone configuration file to a user
> and that gets messy
> timeless.bmo1: i think you're better off changing the example to that of an
> aggregator
> or marketplace

COMMENT/QUESTION: I think I'll leave the comment for now, but if the
issue comes up again I will change it to be more clear. However, if
you *really* think it should be changed, I will change it.

> timeless.bmo1: to standardize a API for widgets
> an API :)
> specifies an API that allows
> like that :)

TYPO: fixed.

> timeless.bmo1: # Safely access services, resources, and other applications
> on a user's device.
> on the user's device

TYPO: fixed.

> 4:18 PM These interfaces must be encapsulated as a self-contained object or
> some similar data structure in a non-object-oriented programming
> environment.
> i need to check my English, i kinda want a comma before 'or'. the sentence
> is too heavy and doesn't balance the way i want...

TYPO: added coma.

> 4:19 PM A conforming specification must specify a set of interfaces that
> expose the properties, methods, and events of an instantiated widget.
> the word the in this sentence is annoying me
> i'm fairly certain you should omit it
> 4:20 PM as written i could have something which has no properties/methods or
> events
> and that'd enable me to easily expose all (zero) of them
> w/ the _the_, you're asking me to actually do work :)

TYPO: removed "the"

> timeless.bmo1: availability of network access, etc. See
> etc.. <- note the second period
> again, etc. is an abbreviation, and needs its own dot, but that dot isn't
> really a period to end a sentence.

TYPO: added "."

> 4:22 PM A conforming specification must specify a set of interfaces for
> dynamically getting and setting preferences that are unique for an
> instantiated widget.
> 4:23 PM ... preferences _for the widget instance_.

EDITORIAL: changed to "A conforming specification MUST specify a set
of interfaces for dynamically getting and setting preferences for the
widget instance."

> To provide a means for authors to allow end-users to dynamically change
> any preferences they may have set in the past.
> preferences => settings

COMMENT: Retaining "preferences" as this is the matches the language
we use in the API spec.

> 4:24 PM actually, the section header should be something like Storage of
> instance specific data

EDITORIAL: R26. renamed to "Storage of Instance Specific Preferences"

> 4:25 PM timeless.bmo1: A conforming specification must define a set of
> states in the lifecycle of the instantiated widget that are able to be
> captured through script.
> 4:26 PM i don't understand
> To allow authors to programmatically capture when a change has occurred in
> either the instantiated widget or possibly even the widget user agent.

EDITORIAL: simplified the text to "To allow authors to capture
state-change events generated by the instantiated widget."

> 4:27 PM timeless.bmo1: The specification MUST NOT require the WUA to send
> events to the widget immediately, and SHOULD allow the WUA to dispatch them
> at its convenience (e.g., because it doesn't want the widget to do work now
> because it's running low on power)

EDITORIAL: It now reads: "A conforming specification MUST define a set
of states in the lifecycle of the instantiated widget that are able to
be captured through script. A conforming specification MUST NOT
require the widget user agent to send events to the widget
immediately, and should allow the widget user agent to dispatch them
at its convenience."

> R28. Network State Change Events
> 4:28 PM the specification MUST NOT guarantee event delivery, as there may be
> cases where a device is running low on power and can not afford to deliver
> them.

EDITORIAL: Text now reads "A conforming specification MUST specify a
means that allows authors to check if the widget resource is connected
to the network. A conforming specification MUST define the scope of
the term "network" and MUST specify a means by which connection and
disconnection events can be captured by an author through script. A
conforming specification MUST NOT guarantee event delivery, as there
may be cases where a device is running low on power and can not afford
to deliver them."

> 4:29 PM how an instantiated widget (or any of its windows) should to
> categorize itself
> "should to categorize" is wrong/bad. probably just drop 'to', although
> 'categorize' is an annoying word

TYPO: dropped "to"
EDITORIAL: categorize --> classify

> more instances of 'etc.' w/ too few periods. i'm not going to flag
> anymore, but they all need to be correct :)
> 4:30 PM Some of these mode changes may require the end-user's attention, in
> which case the widget user agent should find a suitable and non-intrusive
> way to draw the end-user's attention.
> that's kinda self defeating
> perhaps, should provide a way for the user to find out that attention is
> required

EDITORIAL: dropped "and non-intrusive" and modified sentence. It now
reads: "Some of these mode changes may require the end-user's
attention, in which a case conforming specification SHOULD recommend
that widget user agent find a suitable way to draw the end-user's
attention."

> 4:31 PM asking the WUA to somehow draw the user's attn. is invasive.

COMMENT: Agreed, however, how vendors deal with UI issues is an
implementation detail. I think the requirement is probably clear
enough.

> An example of this kind of behavior can be seen on Mac OS X, where a
> program's icon bounces in the dock when a program has a critical window to
> display.
> a Bad example

COMMENT: yep, it's certainly annoying but I think it again captures
the intention.

> 4:32 PM fair enough
> timeless.bmo1: a better example is the iPod touch's mail app which changes
> the widget to include a new mail number in a corner
> no flashing.. really, no flashing

COMMENT: agreed. However, I still think the current example is good enough.

> 4:33 PM but should provide some means of binding to those APIs if they are
> available.
> ... and the user agrees
> SHOULD NOT do so without consulting the user or a policy which exists to
> represent the user.

EDITORIAL: the requirement now reads "A conforming specification
SHOULD specify a mechanism, either through an API or through the
configuration document, which allows instantiated widgets to bind to
third-party APIs that allow access to device-specific resources and
services. A conforming specification is not required to specify any
APIs to device specific resources or services, but SHOULD provide some
means of binding to those APIs if they are available and the user
agrees. A conforming specification SHOULD specify that bindings MUST
NOT occur without consulting the user or a policy which exists to
represent the user."

> 4:34 PM include cameras, SMS, GPS and address book.
> cameras is plural, SMS and GPS are ambiguously plural
> parallelism says address books should be plural

TYPO: fixed.

> timeless.bmo1: A conforming specification must specify the APIs proposed in
> this section in such a way that they are implementable in ECMAScript.
> "are implementable" doesn't include a reasonableness bit
> 4:36 PM (again, i know we have lots of people representing them, but still,
> let's be clear that it's a requirement)

COMMENT: I think the intention of this statement is fairly clear. If
you want to suggest some better text I would be happy to include it.

> To support a language that is already widely used in widget user agents
> and to allow authors to use already existing ECMAScript code libraries.
> 4:37 PM not sure if you mean implementable. if you do, then you don't mean
> authors. because authors by default is widget authors
> whereas if you mean implementable, then you're talking about a different
> group of people
> otoh, you might mean usable
> or you might mean both, in which case you need more sentences :)

QUESTION: Can you suggest some better text for R31. ECMAScript Compatibility?

> 4:39 PM To allow widget to communicate with each other.
> widget s

TYPO: fixed.

> timeless.bmo1: a stock widget stock quotes widget
> the the is usually a spelling error :)

TYPO: fixed.

> timeless.bmo1: the spec SHOULD provide a way for users to be aware of
> widget dependencies and to introduce widgets to each other ("pairing").
> as well as unpairing.
> 4:41 PM if i have a news ticker and a stock ticker, i don't want them
> automatically finding eachother

EDITORIAL: Changed the text of R33. Cross-Widget Communication, to "A
conforming specification MAY specify a model and API to allow multiple
instantiated widgets to securely communicate with each other. A
conforming specification attempting to address cross-widget
communication SHOULD provide a way for users to be aware of widget
dependencies and to introduce widgets to each other ("pairing" and
"unparring")."

QUESTION: does that sound ok?

> 4:42 PM To allow authors to easily access metadata they declared in the
> configuration document at runtime.
> "at runtime" bound wrong
> you need to move it earlier in the sentence
> as written it sounds like the widget created the configuration document at
> runtime :)

EDITORIAL: changed sentence to "To allow authors at runtime to easily
access metadata declared in the configuration document. "

> timeless.bmo1: A conforming specification SHOULD specify a means that
> allows authors to open URLs in a browsing contexts outside the widget
> engine.
> 4:43 PM in a browsing context s ... no bad :) lose one or the other

TYPO: "s" is gone

> timeless.bmo1: The objective of this section is to ensure that a conforming
> specification mandates a language that is well-suited for creating user
> interfaces and is accessible.
> 4:44 PM accessible bound to the language, not the user interfaces :(
> which i would have thought wasn't what you wanted, since i couldn't
> imagine any reason to want an accessible language
> 4:46 PM timeless.bmo1: what you want to be accessible is what's described by
> the language
> not the language itself
> timeless.bmo1: your English document isn't accessible
> and that's risking making the next document also not accessible, which in
> turn could make the final widgets not accessible, while still resulting in
> an accessible product (html documents)

EDITORIAL: new text "The objective of this section is to ensure that a
conforming specification mandates an accessible language that is
well-suited for creating user interfaces."

> 4:47 PM (and yes, that English was awkward, i should have used inaccessible)
> through an non-graphical UI
> an => a

TYPO: fixed

> 4:48 PM The declared interface may also be accessible to screen readers,
> allowing relevant sections of text and functionality to be accessed by
> non-visual means
> MAY implies MAY NOT
> which is um strange
> and boy do i really hate css uppercase
> 4:49 PM timeless.bmo1: dunno... for the working drafts, probably
> since during this time, people will be quoting it
> if you want to switch back to magical form before final publication,
> perhaps


TYPO: all conformance terms to UPPERCASE.

> timeless.bmo1: i think you want SHOULD here btw
> 4:50 PM A conforming specification may recommend that, aside from including
> standard root certificates, widget user agent allow end-users to install
> digital certificates from other trusted sources.
> this may be a disaster
> we had some guy come to irc.mozilla.org yesterday asking for the ability
> to add his own EV root CA
> 4:51 PM bang head against wall
> MAY at its own peril. :)
> me: hold up, "here" means R37?
> timeless.bmo1: 48
> err 38
> sorry :)
> me: "A conforming specification SHOULD recommend that, aside from including
> standard root certificates, wid"
> 4:52 PM timeless.bmo1: SHOULD NOT :)
> besides, installing a certificate is useless, the only thing worth
> installing is a CA Root
> me: hmm... we had explicit requests for that

ISSUE: should we mandate that developers and admins be allowed to
install their own certs?

> 4:53 PM timeless.bmo1: consider this as a request from the mozilla security
> side
> me: ok
> timeless.bmo1: i'm pretty sure i can get it in writing if necessary
> WUAs are already messy enough, and they're the fast path to rooting the
> device
> 4:54 PM so making it remotely easy to add a Certificate of any kind is not a
> good idea
> me: agreed
> timeless.bmo1: WUAs may provide an Author mode to enable authors to test
> their applications with broken certificates
> 4:55 PM not broken certificates actually
> me: can leave that as an implementation detail
> timeless.bmo1: ok
> can you include a requirement for a security sign off on anything dealing
> w/ certificates? :)
> me: I sure can

ISSUE: need a security sign off on anything dealing w/ certificates.

> timeless.bmo1: the rationale: To allow authors and publisher to sign
> widgets.
> is wrong
> 4:56 PM since publishers can already sign them
> they just need to use a WUA trusted CA root to get their signature
> which is a perfectly reasonable requirement
>
> A conforming specification should recommend that widget user agents allow
> end-users to explicitly input a proxy server through which all HTTP-based
> request are made.
> 4:59 PM perhaps you should have a define at the top that says "HTTP" in this
> document means HTTP or HTTPS

COMMENT: addressed by citation.

> timeless.bmo1: "input" is wrong. it's too strong, perhaps "select"

EDITORIAL: input -> select.

> 5:00 PM and as a should, I SHOULD be able to pick a proxy per widget
> however it shouldn't be a requirement (MUST), because some systems won't
> want to
> me: yeah, that adds quite a bit of complexity
> timeless.bmo1: (not all widgets are created equal, some are more equal than
> others)
> me: sounds like a 2.0 feature
> if someone wants it
> 5:01 PM timeless.bmo1: the problem is that i can easily have some widgets
> that i only want to work in some environments
> and some widgets that will need a proxy at some times
> yeah stupid corporate firewalls
> me: yeah, I can already think of use cases
> timeless.bmo1: however, some things shouldn't work at some times
> 5:02 PM i have apps like this
> which may be ip based and don't want them talking to any random server at
> that ip, but only via some trusted proxy... but i don't want all the other
> widgets to use that trusted proxy
> 5:03 PM or in some cases, i really really don't trust the proxy, but it's a
> necessary evil for a certain widget
> me: you think it might be something to consider for 1.0 then?
> timeless.bmo1: sadly yes

ISSUE: End users should be able to specify that a widget only
communicates via a particular proxy.

> Updating must preserve the identity of the widget and should be conducted
> over a secure communication channel.
> there's a 'should' w/o upper case there

TYPO: FIXED

> 5:04 PM then the widget user agent could ask the end-user if they want to
> download the widget.
> 5:05 PM WUA: there's an update for World Clock available, it's 10mb, your
> current bandwidth is 2bpm, and your rate charge is 10EUR/b. Update now? Yes,
> Never.
> that's going to be the default impl, minus the helpful warning about bad
> speed and high cost
> there needs to be a way for the user to defer answers until the user is
> more willing

EDITORIAL: I've rewritten R40. Automatic Updates "A conforming
specification MUST specify a model to allow widget user agents to
automatically check if a new version of a widget resource has become
available online or from local storage. A conforming specification
MUST recommend that an updated widget is downloaded only with the
user's consent and that users be able to cancel or defer updates. An
automatic update MUST preserve the identity of a widget, meaning that
that preferences previously set by the user are retained after the
update process. A conforming specification SHOULD recommend that, when
possible, automatic updates be conducted over a secure communication
channel. "

> timeless.bmo1: To allow widgets to be closed and re-instantiated without
> the end-user having reset the preferences for an instantiated widget.
> timeless.bmo1: "preferences" => "settings", probably a semi global but not
> quite automatic change

COMMENT: Keeping preferences for now.

> 5:08 PM are you providing distinct storage for settings and app data?
> For example, when using a weather widget, the end-user will want to store
> the preferred location for weather information, and not be asked to input
> that information again every time the widget is re-instantiated.
> me: ATM we only have widget.preferences
> 5:09 PM yes
> timeless.bmo1: ... the user will not want to wait for the app to get a
> weather forecast just because the device rebooted
> me: one can store that as JSON in the prefs
> 5:10 PM timeless.bmo1: fine by me. again better to change it to settings (or
> however i called it earlier) instead of prefs
> A conforming specification must recommend that a widget user agent allow
> multiple instances of a widget resource to be instantiated and run
> concurrently as separate processes.
> some platforms have very high per process overhead
> 5:11 PM yes it means one widget can hang the desktop or crash it. but hey,
> we're memory limited at 128mb or 256mb :)
> me: Should probably relax that then
> timeless.bmo1: definitely
> me: should or may?
> 5:12 PM timeless.bmo1: "could but probably should not because it will hurt
> embedded systems with limited resources"
> could suggest that implementations which have enough resources should

EDITORIAL: I split R42 into two parts "A conforming specification MUST
recommend that a widget user agent allow multiple instances of a
widget resource to be instantiated. A conforming specification MAY
recommend that implementations which have sufficient resources (CPU,
memory, etc.) run widgets concurrently as separate processes."

> 5:13 PM timeless.bmo1: To allow multiples instances of the same widget to be
> run at the same time, but possibly be configured differently. For example,
> instantiating two clock widgets where one displays the time for Amsterdam
> and the other displays the time for Boston.
> the example is bad
> see ipod touch clock
> the right reason is because the user may want the two instances to be in
> different locations or views
> i might want to see nyc in analog on one screen in the top right corner
> 5:14 PM and nyc in digital on another screen in the bottom right corner


COMMENT: agree, not the best example, but it gets the point across I think.

> timeless.bmo1: # Insures that widgets won't be able to perform harmful
> operations on end-user's machines or devices.
> 5:15 PM Insures/Ensures. check w/ someone. i think you want the other
> what if i want to use a widget file manager to delete DRM components :)
> or other widgets
> without informed consent :)
> 5:16 PM some operations should be allowed, but only after consulting the
> "user" (or user policy equivalent)
> (yes, i've worked in systems where the user was actually a script and not
> a normal mortal)
> 5:17 PM it might be simpler to define "user" at the top as possibly being a
> robot, policy, automated script, accessibility agent, etc., or maybe a
> child, human, disabled, or animal.
> then you can use "user" freely w/in and i won't keep saying "or user
> policy equivalent" :)

COMMENT: I think it is generally assumed within the working group that
a user is at least one of the things or people you listed above.

> A conforming specification must specify a default security policy that
> limits the privileges afforded to a widget at runtime.
> not enough instances of 'default'
> 5:18 PM as written, the system has one policy, enforce for all widgets
> either the default one, or a replacement
> what you want is replaceable policies per widget.

The following email failed to go into the archive and possibly out to
the group. I've emailed sysreq to make sure it gets into the archive.
In the mean time, here is the plain text edition.


---------- Forwarded message ----------
From: David Rogers <david.rogers@omtp.org>
Date: Fri, Aug 1, 2008 at 9:30 PM
Subject: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
To: public-webapps-request@w3.org, marcosscaceres@gmail.com,
art.barstow@nokia.com
Cc: Nick Allott <nick.allott@omtp.org>


Dear Art, Marcos and all,



Please find attached the OMTP BONDI input to the W3C Web Applications
WG Widget Requirements last call. I've extracted the text of the input
below. Please note this is the first of two sets of input. This first
input contains comments to existing requirements and proposals for new
requirements. The second document contains more general comments,
applicable to the Widget Requirements and also the Packaging and
Configuration work.



Introduction



OMTP is a forum backed by many of the largest mobile operators and has
members from many hardware and software vendors across the value
chain.

It was set up with the aim of gathering and driving mobile terminal
requirements to ensure consistent and secure implementations, thereby
reducing fragmentation and simplifying the customer experience of
mobile data services. OMTP recommendations benefit carriers, content
providers, middleware vendors and handset manufacturers to develop
open and compatible mobile devices. OMTP have created their BONDI
initiative to specifically address the problem of fragmentation in the
evolution of the mobile web and to ensure the protection of the user
from malicious web based services. The BONDI initiative will be
delivering documentation throughout 2008 with the aim of driving
activities in other appropriate standardisation and industry bodies
such as W3C.

Devices supporting some of the features of BONDI will become available in 2009.

This document forms the input from BONDI relating to the security
aspects of the W3C Widgets: 1.0 Requirements found at
http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/.

The document is divided into two parts; the first part details
proposed changes to existing W3C requirements, the second part
proposes new requirements that for inclusion.



Part I - Changes to Existing Requirements Proposed By BONDI



R11. Digital Signature

We suggest the following re-wording of the existing requirement so
that it reads:

"A conforming specification MUST specify a means to verify the
authenticity and integrity of all resources in a widget resource, with
the exception of any resources explicitly excluded by the
specification. A conforming specification MUST provide this capability
by specifying a processing model for generating and verifying a
digital signature associated to a widget resource. The digital
signature scheme MUST be compatible with existing Public Key
Infrastructures (PKI), particularly X.509 digital certificates. In
addition, the recommended digital signature format SHALL support the
ability to include a certificate chain with a digital signature to
enable the receiving device to build a certificate chain from the end
entity certificate used to generate the signature to a locally stored
root certificate. In addition, the recommended digital signature
format SHOULD support the ability for a widget resource to be signed
using multiple end entity keys (i.e. it SHOULD be possible to include
multiple signatures and associated certificate chains)."

The proposed changes attempt to tighten and clarify the use of digital
signatures and certificate chains. In addition we suggest that the
following text should be added to the existing requirement:

"A conforming specification SHALL specify the expected behaviour when
multiple signatures and certificate chains are provided. A conforming
specification SHALL specify that if none of the signatures and
certificate chains can be verified, e.g. because of missing root
certificates or where any certificates in the chain have expired or
are not yet valid, then the widget resource SHALL be treated as
unsigned. A conforming specification SHALL specify that the widget
environment SHALL not install or load a widget resource when it can
determine that any certificate in the chain has been revoked."

This addition is to ensure that there is a consistent behaviour when
verifying signatures and certificate chains, especially in error cases
in which the verification fails because of missing certificates and in
which one of the certificates has been revoked. We use the term load
to cover the case in which a widget is not subject to an installation
event.



In addition, we suggest the following changes to the Rationale:



"To provide a means to verify authenticity, check data integrity, and
provide a means of non-repudiation for users." to "To provide a means
to verify the authenticity, check the data integrity and provide
persistent proof of origin of the widget resource."

"a digital signature" to "are digitally signed"

And the following addition:



"The ability to provide certificate chains with signatures is vital,
particularly in the mobile world, to allow end entity certificates to
be chained to a locally installed root.



The ability to include multiple signatures can help address the issue
that target devices may have different root certificates installed.
Equally there SHOULD be defined behaviour for what happens when a
required root isn't available. Treating this case as an error case
(and therefore not allowing the installation of the widget) has been
seen to encourage developers not to get the applications signed
whereas allowing this case but treating widgets as unsigned doesn't
provide the same disincentive."





R21. Security Declarations

We suggest the addition of the following text to the existing requirement:



"This SHALL include a means of declaring the APIs that a widget
expects to access. A conforming specification SHALL provide a means to
verify the authenticity and integrity of security declarations
included in the widget resource."



The reason for this suggested addition is to make it explicit that it
must be possible to include required APIs in the security
declarations. In addition, we suggest that the security declarations
should be treated as a protected resource as the authenticity and
integrity of this information is essential if it is to be used when
making security decisions.



These proposed modifications are based on the assumption that security
declarations are included in the configuration document, which can be
used independently of the widget resource, as stated in R.23. If this
is not the case then an additional requirement is needed to ensure
that the security declarations can be used independently of the widget
resource.





R38. Additional Digital Certificates

We suggest that the requirement is re-worded along the following lines
"A conforming specification SHOULD define mechanisms to enable
end-users to install additional root certificates, provided this is
compatible with the security policy of the widget processing
environment."

The reason for this proposal is that the existing requirement seems to
suggest that the user should always be able to install additional root
certificates on their device whereas in our opinion this capability
should be controlled by the security policy of the device. In
addition, we have removed the reference to standard root certificates
as this implies a set of root certificates that are common across all
devices.

In addition, we suggest that following text is added to the rationale
"using self-signed or test certificates, and install these test
certificates on a device in order to test their widget on a real
device." as this links more closely to the requirement.





R43. Default Security Policy

While we agree that it is a requirement to be able to specify a
default security policy, and that this should err on the side of
caution, we would like to seek clarification of this requirement?



For example, is the intention to mandate static declarations of
requested permissions or are programmatic requests also to be allowed?



We would also like to indicate that BONDI are currently working on a
policy framework and the definition of default or recommended policies
and policy configurations and would like to co-ordinate this work with
W3C.





R44. Runtime Security Exceptions

In the sentence "A conforming specification MUST specify runtime
exceptions for when the API attempts to perform an action it is not
authorized to perform." suggest that "API" is changed to "widget" as
this seems to fit in better with the rationale?

Normative references

We suggest that the reference for X.509 is updated as follows:



X.509

RFC 3280: Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile, R. Housley. IETF, April
2002. Available at: http://www.ietf.org/rfc/rfc3280.txt

Part II - New Requirements Proposed By BONDI



The following text proposes new requirements, related specifically to
security mechanisms that have been derived from ongoing work within
BONDI.





RXX. Signature Document Independence

A conforming specification MUST specify the digital signature format
in such a way that the signature value(s) and associated certificate
chain(s) can be used independently of the widget resource that is
covered by the digital signature. A conforming specification SHOULD
provide guidelines for how the signature(s) and certificate chain(s)
can be used separately from a widget resource. A conforming
specification SHOULD specify a means to provide the independent
signature document in conjunction with the independent configuration
document (see R23).

Motivation:

Web and offline distribution, device independence current development
practice or industry best-practices



Rationale:

To allow the signature information to be extracted and used by other
applications (either on the server or on the client side) for
different purposes. For example, a server may automatically extract
the signature information from a widget resource and serve it upon
request. The independent signature information may then be used, for
instance, to provide the user with information about the source
(signing entity) and associated trust level of the widget without
needing to download the complete widget resource. Additionally, if
combined with security declaration information, the signature
information may allow a security decision to be made about whether or
not the widget will run properly, enabling a further decision to be
made as to whether to continue to download and install the widget.
This may be particularly useful for users of widgets on mobile
devices, where the cost of downloading data can sometimes be
expensive.



Comment:

This is common practice in the mobile world with Java applications.
The purpose of pre-verifying elements of the signature and certificate
chain is to address the case in which a widget provided by a
non-malicious developer fails to install because for example, the
certificate is out of date or no revocation information is available.
It also allows parallel OCSP round trips while downloading widget
resource (as is done for Java apps in the mobile world)





RXX. Independence of Non-Security Critical Information from Digital Signature

A conforming specification SHOULD make it possible to change
non-security critical information associated to the widget resource
without having to re-sign the widget resource. The non-security
critical information may or may not be included in the widget package.
A conforming specification SHALL specify which information can be
considered non-security critical. A conforming specification SHOULD
specify a means to provide this non-security critical information in
conjunction with the independent configuration document (see R23).



Motivation:

current development practice or industry best-practices

Rationale:



Some information associated to the widget resource might need to be
changed during ingestion (e.g. version, provider, name etc.). This is
common when a single developer provides the same content to a number
of re-sellers. It may be that the same information needs to be
provided with the configuration document.





RXX. Signing Procedure Agnostic

A conforming specification SHALL specify a mechanism for signing a
widget resource that does not explicitly or implicitly impose any
restrictions on the procedure for generating the signature. More
specifically, a conforming specification SHALL allow the use of end
entity keys stored in a secure module in a hosted environment. A
conforming specification SHALL specify that implementations SHOULD be
able to use end entity keys via a PKCS#11 interface.



In addition, the mechanism SHALL make it feasible for end entity keys
to be used once and then securely deleted.



Motivation:

Security, current development practice or industry best-practices

Rationale:

To enable signing schemes to provide assurances that a high level of
end-to-end security has been maintained around the signing process, in
particular assurance that the signing key has not been compromised.
PKCS#11 is the most widely supported standard interface for hardware
security modules.





RXX. Support for Multiple Message Digest Algorithms

A conforming specification SHALL specify that where the integrity of
data is protected using a message digest, it SHALL be possible to use
the SHA-1 message digest algorithm and SHALL be possible to use the
SHA-256 message digest algorithm.



Motivation:

Security

Rationale:

Due to known weaknesses in the SHA-1 algorithm and the expected
lifetime of implementations it is prudent to strongly recommend
support for SHA-256 to ensure that the overall security of the
solution is maintained.





RXX. Support for Multiple Signature Algorithms

A conforming specification SHALL specify that where digital signatures
are used it SHALL be possible to use the DSA signature algorithm and
SHALL be possible to use the RSA signature algorithm.



Motivation:

Security

Rationale:

Security best practice: to support two algorithms to mitigate against
the risk that weaknesses are found with a selected algorithm.





RXX. Key Lengths

A conforming spec SHALL specify that widget processing environments
SHALL support RSA with key lengths up to at least 2048 bits and SHALL
support DSA with key lengths up to at least 2048 bits (see NIST
Recommendation). A conforming spec SHALL recommend that widget signing
tools SHALL support and use RSA with key lengths of at least 2048 bits
and DSA with key lengths of at least 2048 bits (see NIST
Recommendation).



Motivation:

Security

Rationale:

To be in-line with current security recommendations and provide
longevity of the system security. In some use cases it may be
desirable to use key lengths of less than 2048 bits, e.g. where the
impact on performance outweighs the additional security afforded.





RXX. Key Usage Extension

A conforming specification MUST specify the expected use of valid key
usage extensions and when present (in end entity certs) MUST specify
that implementations verify that the extension has the
digitalSignature bit set.



A conforming specification MUST specify that implementations recognize
the extended key usage extension and when present (in end entity
certs) verify that the extension contains the id-kp-codeSigning object
identifier. A conforming specification MAY also define a new OID
specifically for widget signing, and specify that implementations
verify that the extended key usage extension in the end entity cert
contains this new OID.



Rationale:

To maintain compliance to RFC 3280 (experience suggests that if this
is not explicitly required then the RFC 3280 is not followed when it
comes to key extension usage).



Compliance ensures that only certificates intended to be used (issued
for) code signing can be used to sign widget resources.



Comments:

Using the extended key usage extension "id-kp-codeSigning" would in
theory allow the same end entity certificate to be used to sign any
executables including widgets, Java applets and native executables.
However, it should be possible to restrict the use of a particular end
entity certificate so that it can only be used to sign certain a
certain type (or types) of executables by associating a usage
restriction with the root certificate to which the end entity
certificate is chained.





RXX. Inclusion of Revocation Information

A conforming specification SHOULD specify a means of packaging
up-to-date revocation information with digital signature and
associated certificate chain (e.g. a CRL or OCSP response stating that
certificate has not been revoked). In addition, a conforming
specification SHOULD specify the behaviour in the case that the
revocation information is not included or not complete. A conforming
specification SHOULD specify that if the revocation information is
present the widget processing environment MUST attempt to verify the
revocation information. A conforming specification SHOULD specify the
behaviour if revocation information is out of date or otherwise
invalid.



In addition, the mechanism specified SHALL not require the widget
resource to be re-signed to include new revocation information.



Rationale:

To provide up-to-date revocation information, when it is needed by the
widget engine, without requiring a query to an online CRL or OSCP
server from each device. This is a lot more efficient and eases the
load on CRL or OSCP servers.









-------- END OF DOCUMENT --------









Many thanks,





David.



David Rogers
OMTP Director of External Relations
m: +44 (0) 7771 838197 david.rogers@omtp.org
skype: dg.rogers

linkedIn: http://www.linkedin.com/in/davidrogersuk

OMTP Ltd.
Marble Arch Tower
55 Bryanston Street
London
W1H 7AJ

www.omtp.org

P Please consider the environment – don't print this mail unless you
really need to...

Hi,

This note is on behalf of the I18N Core WG. The comments (below) that I sent to members of your WG previously have been endorsed by the I18N Core WG [1], with the following additional comments:

1. In my comment #3 below, we would strongly prefer the second suggested paragraph (MUST rather than SHOULD).

2. In my comment #15 below, we feel that it would be best if the charset parameter were required (MUST) and think that it should at least be strongly recommended (via the SHOULD keyword).

Finally, (this comment is personal and not yet endorsed by I18N-WG), I note that the text in [2] still has a few flaws (this is "Step 6"), as it is confusing and doesn't really describe the lookup algorithm cleanly. There first two paragraphs are fine, but the remainder I would suggest changing to read (notes on changes follow //):

--
The algorithm to determine the base URI and widget locale are as follows:

1. If the lang-priority-list is empty, or null, or i-default, or contains a single *, or is a sequence of items that only contain the * character, then terminate this algorithm and attempt to locate the configuration document.
// deleted the 'default' keyword
2. For each range in the lang-priority-list:
a. If this range is a single *, then terminate this algorithm and attempt to locate the configuration document.
// dropped "and this is the first subtag in the l-p-l"
b. Else if this range begins with the subtag '*', then skip this range and, skipping all the steps below, repeat this step 2.
c. Else if this range contains a subtag "*", remove the "*" and its preceding hyphen and continue. For example, "en-*-US" becomes "en-US".
// skip ranges that start with *, which are indeterminate
d. Case-insensitively compare the range to each file name field for each file entry that is a folder in the widget resource.
i. If they match:
1. Let widget locale be the name of the folder that matched the current range in lowercase form.
2. Let base URI be an absolute URI reference to this same folder.
3. Terminate this algorithm and attempt to locate the configuration document
ii. Else, remove the last subtag of the range and repeat this step 2d. For example, if the range is currently "en-US", make the range "en".
3. If no match is made, attempt to locate the configuration document.

For example, if the range is "en-AU" and a match is made on file entry whose name is "en-au/config.xml", then base URI would be "widget://f81d4fae-7dec-11d0-a765-00a0c91e6bf6/en-au", and the widget locale would be "en-au".

For example, if the language priority list is "de-CH,fr-CH,it-CH" and folders included "de", "fr-FR" , and "IT", then the folder "de" would be matched, then base URI would be "widget://f81d4fae-7dec-11d0-a765-00a0c91e6bf6/de"and the widget locale would be "de".


--



[1] http://www.w3.org/2008/07/23-core-minutes.html#item04

[2] http://dev.w3.org/2006/waf/widgets/#widget12



Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization Core WG

Internationalization is not a feature.
It is an architecture.


-----Original Message-----
From: Phillips, Addison
Sent: Thursday, July 10, 2008 2:02 PM
To: public-i18n-core-comments@w3.org
Cc: Marcos Caceres; Arthur Barstow; Felix Sasaki; mike@w3.org
Subject: RE: Widgets i18n feedback

Hi,

My personal comments on the Widgets specs located at [1] follow. I have copied a few members of the WebApps WG on this message so they can see progress; these comments will be a Topic in our next teleconference, for consideration as the Internationalization WG's official comments.

Comments follow.

First, the requirements document:

1. In the introduction we see the (much better) comment:

--
As argued by the Widget Landscape document, there is currently no formally standardized way to author, package, digitally sign and internationalize a widget resource for distribution and deployment on the Web.
--

The widget-land document focuses on localization of widgets, which is important. This document should provide a solution to the above and this should be referred to as "localization". Internationalization remains a problem because JavaScript has no locale facet. Internationalized formatting and processing is only possible as long as one is happy with the default system locale and formats on the host platform. Note: this is usually less of a problem for widgets than for AJAX style interactions in a Web page, since most widgets are perceived as applications running locally, whereas most Web properties manage the user language/locale themselves and need a locale in JS to "do the right thing".

2. [R5] "For example, addressing a resource via an IRI (e.g. new Image('../images/pane.png'))."

The use of IRI here is good to see.

3. [R6] Multilingual Resource Names. The current text is not really as strong as I'd like it to be (as you probably would suspect). I'm also not sure that it's quite correct. The current text reads:

--
A conforming specification SHOULD recommend a packaging format that is suitable for multilingual contexts, giving authors the ability to name files and directories using characters from the Unicode character repertoire; in such a case, a conforming specification SHOULD recommend the UTF-8 encoding.
--

Keeping the same "strength" of requirement, I would probably phrase this as:

--
A conforming specification SHOULD recommend a packaging format that allows for non-ASCII characters in file and directory names, allowing authors to create widgets suitable for various cultures and languages, as well as multilingual contexts. The packaging format MUST either provide for a declaration of the character encoding used or specify what it is. The UTF-8 character encoding SHOULD be either the default (if multiple encodings are allowed) or sole encoding used.
--

It would be far better to strongly require encoding support:

--
A conforming specification MUST declare the character encoding of file and directory names used in the packaging format and SHOULD use the UTF-8 character encoding. If the UTF-8 encoding is not used, the specific encoding MUST either be specified by the packaging format or be specifiable in the package itself. Since packaged widgets are widely distributed, variation in character encoding between different platforms or configurations may render a widget with non-ASCII resources inoperable or otherwise degrade the user experience unless a comment character encoding is used.
--

4. [R7] Internationalization guidelines. Really this should be "localization guidelines", since internationalization support is not really dealt with anywhere.

5. [R14] Authorship and Widget Metadata. Note that the author's name, email, and organization can all be non-ASCII values.

Next document: [1a]

6. "File and Folder names". This section contains the following text:

--
Author requirements: The zip relative path must be encoded as either [CP437] or [UTF-8]. Encoding the file name field using [UTF-8] is recommended. If the zip relative path is encoded using [UTF-8], then the general purpose bit 11 of the local file header must be set to 1, otherwise it must be set to 0.
--

This is good (and addresses my comment 3).

7. (same section). The text says:

--
Author requirements: It is recommended that authors keep their path lengths below 255 characters. Having excessively long path names (eg. over 120 characters) can also result in interoperability issues on some operating systems.
--

I'm pretty sure you do not mean "characters" here. You probably mean "bytes", since that is the limitation on some operating environments. In a multibyte encoding, such as UTF-8, this means that there may be fewer than 255 characters in a 255 byte sequence (as few as 63 in the worst case). Please use the word "bytes" here if that is what is meant and include a note along the lines of: "Note that a character can require more than one byte to encode, making the length of the path in characters less than 255."

8. [non-i18n] I think you mean to s/260/255 in this note:

Note for implementers: as this specification does not put a restriction on path length, implementers need to be prepared to deal with path lengths longer than 260 characters.

9. [non-i18n] The "valid zip relative path" ABNF is flawed. It has a production called 'ascii-chars', but both utf8-chars and cp437-chars use 'ascii-range' instead.

10. Section 6. The example has no language attributes, non-ASCII, or IRI-style values. Probably this example is fine, but it is always nice to see examples that use international capabilities.

11. "Attribute Values and Types". Put quotes around the example numbers to make clear where they are. Some cultures use comma as a decimal separator and it will be clearer what your examples are if you do this.

12. "URI attribute" You specify BOTH URI and IRI here. And you specify path as being strictly URI (3986). But elsewhere you consistently use the term IRI. Even more confusingly, the word "token" doesn't even appear in 3986 and appears only once (in another context) in 3987. I think you should specify the specific format, preferably IRI.

13. The "name" and "description" elements (6.5, 6.6). Here are human readable strings with no xml:lang. You should allow an xml:lang on these elements. Ideally, you should permit multiple descriptions (at least) in multiple languages. These elements are often displayed in widget management environments (before the widget is invoked or running).

14. The "author" element (and its attributes) (6.7) The uri and email attributes should both be of the IRI-flavor, although non-ASCII email names are currently controversial.

15. The "content" element (6.11) The default 'type' is "text/html" with no charset. It would be better if the default included a charset. The 'src' attribute uses the word "URI", where you should say "IRI".

16. Section 7. "widget locale". This is specified as:

--
widget Locale
The system locale as an RFC3066 language code (eg. en-us)
--

This should say "The system locale as a BCP 47 language tag (e.g. en-US or zh-Hant-TW)"

17. In this same section, "rules for getting text content": I notice that any bidi markup will be removed.

18. General observation: there is no way to set base directionality (for bidi text) on any of the description/name/etc. elements or for the widget overall. This may make some bidi languages (Arabic, Hebrew, Urdu, etc.) work poorly in a widget.

===

That's it for now.


Best Regards,

Addison


[1] http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/

[a] http://www.w3.org/TR/widgets/



Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: Michael(tm) Smith [mailto:mike@w3.org]
> Sent: Wednesday, July 09, 2008 8:10 PM
> To: Phillips, Addison; Addison Phillips
> Cc: Marcos Caceres; Arthur Barstow; Felix Sasaki
> Subject: Re: Widgets i18n feedback
>
> Addison,
>
> We really need to get your input on this by the week of July 28 at
> the latest.
>
> --Mike
>
> Marcos Caceres <marcosscaceres@gmail.com>, 2008-07-01 11:41 +1000:
>
> > Hi Addison,
> > I'm just wondering if you could give us an ETA on the i18n input
> for the
> > Widget spec?
> > Kind regards,
> > Marcos
>
> --
> Michael(tm) Smith
> http://people.w3.org/mike/

> http://sideshowbarker.net/

Hi Art,
The MWBP WG consolidated comments are attached as a HTML document.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org
<mailto:public-bpwg-request@w3.org> ] On Behalf Of Arthur Barstow
Sent: Thursday, July 31, 2008 5:25 AM
To: public-bpwg@w3.org
Cc: ext Marcos Caceres
Subject: Fwd: Request for Comments on Widgets 1.0 Requirements Last Call
WD


This is a reminder August 1 is the end of the comment period for the
Widgets 1.0 Requirements Last Call Working Draft.

-Regards, Art Barstow


Begin forwarded message:

> From: Arthur Barstow <art.barstow@nokia.com>
> Date: June 26, 2008 4:46:23 PM EDT
> To: public-bpwg@w3.org
> Cc: Marcos Caceres <m.caceres@qut.edu.au>
> Subject: Request for Comments on Widgets 1.0 Requirements Last Call WD
>
> Dan, Jo, MWBP WG,
>
> On June 25 the Web Applications WG published a Last Call Working Draft
> of the Widgets 1.0 Requirements document:
>
> [[
> <http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/
<http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/> >
> Abstract: This document lists the design goals and requirements that a
> specification would need to address in order to standardize various
> aspects of widgets. Widgets are small client-side Web applications for
> displaying and updating remote data, that are packaged in a way to
> allow download and installation on a client machine, mobile phone, or
> mobile Internet device. Typical examples of widgets include clocks,
> CPU gauges, sticky notes, battery-life indicators, games, and those
> that make use of Web services, like weather forecasters, news readers,
> email checkers, photo albums and currency converters.
>
> Introduction: A widget is 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 or mobile device. A widget may run as a stand alone
> application (meaning it can run outside of a Web browser), or may be
> embedded into a Web document. In this document, the runtime
> environment on which a widget is run is referred to as a widget user
> agent and a running widget is referred to as an instantiated widget.
> Prior to instantiation, a widget exists as a widget resource. For more
> information about widgets, see the Widget Landscape document.
> ]]
>
> We would appreciate any comments your WG has on this LC document,
> especially those requirements relevant to your WG's domain/scope.
> The comment period ends 1 August 2008.
>
> -Regards, Art Barstow
>

+1, not that Ihave a vote <g>
chiming in here on this,

You might pick this up, but one instance of language is written as
"langauge".

for symetry, compactness and accuracy I suggest:
replace "assistive technologies such as screen readers" with:
"screen readers and other assistive technologies"
----- Original Message -----
From: "Steven Faulkner" <faulkner.steve@gmail.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: "Arthur Barstow" <art.barstow@nokia.com>; "Sally Cain"
<sally.cain@rnib.org.uk>; "Cynthia Shelly" <cyns@exchange.microsoft.com>;
<wai-xtech@w3.org>; "public-webapps" <public-webapps@w3.org>
Sent: Tuesday, August 05, 2008 4:22 AM
Subject: Re: Request for Comments on Widgets 1.0 Requirements Last Call WD



+1

2008/8/5 Marcos Caceres <marcosscaceres@gmail.com>:
> Hi Steve, Cynthia, and Sally,
>
> On Tue, Aug 5, 2008 at 12:54 AM, Steven Faulkner
> <faulkner.steve@gmail.com> wrote:
>> Hi Marcos and Arthur, thanks for taking the comments into account.
>
> No probs. Thanks for taking the time to provide them.
>
>> can I suggest the last part:
>> "The user interface language MUST also be accessible to screen
>> readers, allowing relevant sections of text and functionality to be
>> accessed by non-visual means."
>>
>> be replaced with something like:
>>
>> "The name, role and state of all interface elements MUST be available
>> to assistive technologies such as screen readers, to allow relevant
>> sections of text and functionality to be accessed"
>
> Ok. Done.
>
>>
>> and the rationale be modified:
>>
>> from
>> "screen readers and similar assistive technologies"
>>
>> to
>> "screen readers and other assistive technologies"
>
> Ok, below is the final text which hopefully addresses everyone's
> comments. To assist me with the Last Call Disposition of Comments,
> could you please acknowledge if you are satisfied (or not) with what
> is now in the spec:
> --
> R37. Language Accessibility
>
> A conforming specification MUST specify that the language used to
> declare the user interface of a widget be either HTML or a language
> that is accessible at the various levels specified by the WCAG 2.0
> (perceivable, operable, understandable, and robust): specifically, the
> langauge MUST provide keyboard access to interactive graphical
> elements, and provide means to access the widget's functionality
> through a non-graphical UI. For the user interface language, the role
> and state of all interface elements MUST be available to assistive
> technologies such as screen readers, to allow relevant sections of
> text and functionality to be accessed.
>
> Motivation:
>
> Compatibility with other standards, current development practice or
> industry best-practices, ease of use, accessibility.
>
> Rationale:
>
> To recommend a language, or a set of languages, that will allow
> authors to realize their designs, while at the same time remaining
> accessible to screen readers and other assistive technologies.
>
> --
>
> Thank you all again for taking the time to comment and improve this
> requirement.
>
> Kind regards,
> Marcos
>
> --
> Marcos Caceres
> http://datadriven.com.au
>

Here are some comments -

An XML Digital Signature reference is defined but never referenced.
Also, the reference description and 2nd URL needs to be updated to
reflect the date of the 2nd edition (June 2008) and the authors. You
list the editors, but the authors is probably more appropriate.

R11. Digital Signature

s/Private Key Infrastructure/Public Key Infrastructure
s/packaged/package

What version of X.509 are you referencing? v3, v4?

R44. Runtime Security Exceptions

s/an action it it/an action it is

--Sean

Frederick Hirsch wrote:
> Can members of this WG please take a look at the Widgets 1.0:
> Requirements spec, per the WebApps WG request? (see below)
>
> Please send any comment to the WebApps Working Group's public mailing
> list _public-webapps@w3.org_ <mailto:public-webapps@w3.org> (_archive_
> <http://lists.w3.org/Archives/Public/public-webapps/>) and cc this list.
>
> Thanks
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> Begin forwarded message:
>
>> From: Arthur Barstow <art.barstow@nokia.com
>> <mailto:art.barstow@nokia.com>>
>> Date: June 19, 2008 9:10:41 AM EDT
>> To: Chris Lilley <chris@w3.org <mailto:chris@w3.org>>, chairs@w3org,
>> Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>, Mary Ellen Zurko
>> <Mary_Ellen_Zurko@notesdev.ibm.com
>> <mailto:Mary_Ellen_Zurko@notesdev.ibm.com>>, Frederick Hirsch
>> <frederick.hirsch@nokia.com <mailto:frederick.hirsch@nokia.com>>,
>> Addison Phillips <addison@amazon.com <mailto:addison@amazon.com>>, Al
>> Gilman <Alfred.S.Gilman@ieee.org <mailto:Alfred.S.Gilman@ieee.org>>,
>> Jo Rabin <jrabin@mtld.mobi <mailto:jrabin@mtld.mobi>>, Daniel
>> Appelquist <Daniel.Appelquist@vodafone.com
>> <mailto:Daniel.Appelquist@vodafone.com>>
>> Cc: ext Marcos Caceres <marcosscaceres@gmail.com
>> <mailto:marcosscaceres@gmail.com>>, Mike Smith <mike@w3.org
>> <mailto:mike@w3.org>>, Doug Schepers <schepers@w3.org
>> <mailto:schepers@w3.org>>, Charles McCathieNevile <chaals@opera.com
>> <mailto:chaals@opera.com>>
>> Subject: Transition Request: Last Call WD of Widgets 1.0 Requirements
>>
>> Chris, All,
>>
>> On June 19 the WebApps WG agreed [Decision] to publish a Last Call WD
>> of the "Widgets 1.0: Requirements" spec [Reqs] (see also [Abstract]
>> and [SOTD]).
>>
>> Regarding dependencies with other groups, we are not aware of any
>> dependencies.
>>
>> The review period will end August 1.
>>
>> Dave, Mez, Frederick, Addison, Al, Jo/Daniel - we explicitly seek
>> comments from your WGs: UWA, WSC, XML Security, I18N Core, P&F and
>> MWBP, respectively. Of course we also welcome comments from other WGs.
>>
>> -Regards, Art Barstow
>>
>> [Decision] <http://www.w3.org/2008/06/19-webapps-minutes.html#item04>
>> [Reqs] <http://dev.w3.org/2006/waf/widgets-reqs/>
>> [Abstract] <http://dev.w3.org/2006/waf/widgets-reqs/#abstract>
>> [SOTD] <http://dev.w3.org/2006/waf/widgets-reqs/#status>
>>
>>
>>
>>
>>
>>
>>
>

Sean said:
Not sure, but I would be more inclined to reference RFC 5280:
http://www.ietf.org/rfc/rfc5280.txt

Marcos,
Here are my comments on the Requirements (W3C Working Draft 23 June 2008)


> 1. Introduction
> [...] This document does not address the requirements of "web widgets", such
as iGoogle Gadgets or Windows Live Gadgets.
I Think we can add a wording at the end of the sentense to read: ³...,
although this version of the widget specification, the Working group will
address the web widget in the next iteration of the widgets specifications.²

> 3. Design Goals
> Longevity: ...
I think in this chapter we should talk about the versioning of a widget. I¹m
not sure it should be presented as a specific item, or if it can be added
inside the logevity section in relation to the longevity of the content
provided and related updates it will need over time.

> R7. Internationalization Guidelines
> Rationale: [...] (e.g. 'resources/en/' for all English content,
'resources/en-au/' for further localized Australian-English content, and so on).
Insert an ³and² in between the 2 english example to stress the need to allow
both

>R15 & R16
Is there a reason why they should not be ³must² instead of ³should²?

> R19. Iconic Representations
> Rationale: [...] For example, an a small graphic of a calendar may represent a
calendar widget.
³an a² should be corrected
But I propose to add the following after: ³And a small graphic of today¹s
calendar page may also represent this same calendar widget²

> R27. Widget State Change Events
This requirement must be available both ways, you should be able to capture
the change of state when it happens, but you should also be able as an
author to force the state change as well. I propose the following text:
³A conforming specification must also allow the author to programmatically
change the state of the widget to allow a change in the view of the
instantiated widget.²

> R28. Network State Change Events
In the specific case of a network drop, the author will need to know when
the network works again, in order to not have to code a checking loop, it is
important to put together a mechanisme whereby it¹s the widget engine that
wakes up the widget when the network is back on.
What do you think?

> R29. Modal Priority
> [...] (or any of its windows) should to categorize itself
³should to...² should be corrected

> 4.5 User Agents
> R39. End-user Declared Proxy
> A conforming specification should recommend that widget user agents allow
end-users to explicitly input a proxy server through which all HTTP-based
request are made.
This requirement should include at the end ³, or in case of availability,
that the system wide proxy is used.²
This requirement should be a ³Must²

>R40. Automatic Updates
This requirement should be a ³Must²

>R41. Persistent Storage of Preferences
> A conforming specification must recommend that a widget user agent implement
a means to persistently store user preferences for each instantiated widget.
The following should be added after the first sentence: ³This Storage
mechanism must allow to keep the preferences after restart of the widget or
on the restart of the user agent.

> Rationale: To allow widgets to be closed and re-instantiated without the
end-user having reset the preferences for an instantiated widget. For example,
when using a weather widget, the end-user will want to store the preferred
location for weather information, and not be asked to input that information
again every time the widget is re-instantiated.
And again at the end of this sentence: ³The same would apply if the user has
setup 2 instances of the same widget and would like to view 2 different
cities. After closing the widgets, open 2 instances of this weather widget
would automatically pick up the 2 pre-set cities.

> R41 and R42
I would switch them arround so that the notion of the multiple instance can
be used in the Preference Storage Requirement.

> R44. Runtime Security Exceptions
A conforming specification must specify runtime exceptions for when the API
attempts to perform an action it it not authorized to perform.
Correct ³it it²


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
>




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