Comments on Widgets 1.0: Requirements LCWD

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?

Received on Saturday, 26 July 2008 00:15:28 UTC