- From: Bert Bos <bert@w3.org>
- Date: Wed, 28 Feb 2007 18:06:04 +0100
- To: public-appformats@w3.org
Hello WAF WG, hello Art, Here are my comments on the February WD of widgets-reqs. On the whole, I think the document is easy to read and the requirements are good, but not ambitious enough. The biggest omissions are (requirements on) the UIDL and the details of device independence & accessibility. Only R17 talks about alternative manifestations, but then only mentions fallbacks and doesn't require that a widget's functionality (i.e., everything except its interface) should be available on all interactive devices, big or small screen, graphical or not. A widget, being a program, will necessarily be less device independent than an HTML document (you can't realistically print it and use it on paper), but as long as you have an interactive computer with some input device and some output device, the widget should be functional (which isn't the same as user-friendly or useful, of course). Here are the details: 1. Introduction COMMENT 1) What does "currently" mean in the sentence "the host runtime environment typically includes APIs that provides [sic] functionality that is currently specific to widgets"? Are you planning to extend the requirements to other things than widgets in the next draft? And if so, to what? COMMENT 2) Typo: "provides" -> "provide" COMMENT 3) Typo: "environment" -> "environments" in "some host runtime environments include root certificates that host runtime environment can use to check the authenticity of digital certificates." COMMENT 4) Ad "Please let us know if there any good use cases for encryption": A widget is a piece of information, just like an e-mail, and you might want to protect it from spies. That said, I think it is not a requirement of the widget format itself to provide such protection. Generic methods, such as e-mail encryption or SSL are probably adequate. 1.1. Standardizing Widgets COMMENT 5) Ad "The Working Group hopes that by standardizing widgets developers will be able to author, package and deploy their widgets": missing comma after "standardizing"? or after "widgets"? COMMENT 6) Ad "TODO": Possible advantages for users include: fewer VMs to install, widgets that communicate with other widgets, more choice in VMs. Advantages for vendors: no bootstrapping problem when launching a new VM, because there will already be content for it. 1.1.1. Terms Related to widgets COMMENT 7) The Java VM seems to be a "host runtime environment" under this definition and yet it is not mentioned anywhere. I have the impression that the authors of the WD feel that Java programs and Java applets are not widgets. Is that true? And if so, shouldn't it be made explicit why that is so? COMMENT 8) Ad "manifest": I was expecting the word "metadata" in this paragraph. (Not strictly necessary, just a way to confirm to the reader that that is indeed what the definition talks about.) COMMENT 9) Typo: remove "directories" in the sentence "resources [...] may have directories versions tailored for localization purposes." 1.1.2. Standardizable Aspects of a Widget COMMENT 10) Ad "The APIs that authors can use": Should this mention CC/PP, Delivery Context and Media Queries? It's probably a good idea to re-use existing vocabularies in designing these APIs. COMMENT 11) Why aren't the UIDL and the programming language of the widgets among the standardizable aspects? If the MIME type defines just the packaging, the manifest and the metadata, then it doesn't actually tell you which runtime environment to launch, which conflicts with requirement R1. Also, although the packaging and manifest may later turn out to be useful on their own, the immediate need is for a complete widget format. The proprietary formats mentioned in the WD all define how to write actual widgets (but mutually incompatible ones). In fact, R28 (see comment 28) requires ECMAScript and R22 (see comment 24) requires OOP, so it seems the WD does consider the programming language standardizable. 2. Design Goals COMMENT 12) Ad "Compatibility with other standards": I don't think this is a requirement on its own. It's subordinate to "ease of use." Ease of use can often be helped by building on the users' existing knowledge, including well-known standards, but that's just a rule of thumb, not a requirement. COMMENT 13) Ad "Device independence": Missing "e.g.," after "that" in the sentence "The standardizable aspects of a widget must support relevant device independence guidelines so that it is possible to run widgets on mobile devices." COMMENT 14) Typo: Add "of" after "fragmentation" in "Reduce fragmentation widget development space." (Trying to imagine what a "fragmentation widget" is and why it's bad :-) ) R13. Authorship Metadata R14. Copyright Notice and License Metadata COMMENT 15) I think authors like to have a clear place for author, date and copyright (as shown by JavaDoc, e.g.), but to call it a requirement to provide that space goes a bit too far. Maybe it should be a requirement that the widget package has space for free-form comments, e.g., a README file. R15. Visual Rendering Dimensions and Initial Position COMMENT 16) Can this information conflict with information in the UIDL? And if so, what happens? COMMENT 17) It should be a requirement that the user always has the final say. When the widget is displayed by a tiling window manager, e.g., the position and size may not be what the widget writer wanted. R16. Application Bootstrapping COMMENT 18) Typo: delete "an" in "such as referencing via a relative IRI the an initial resource." R18. Default Preference Values COMMENT 19) In a multitasking environment, a program cannot always put itself on top of all other programs on the screen. The widget (or some window of the widget) can categorize itself as critical and then it is up to the OS or window manager to find a suitable way to inform the user. E.g., Mac OS X bounces the program's icon in the dock when the program has a critical window to display. That way other programs are not interrupted and don't loose the focus. So the requirement should be that the widget (or any of its windows) can categorize itself as critical, floating, output-only, etc., which may cause some environments to treat it specially. R20. XML COMMENT 20) It's always a good idea to check if XML is a useful format for some task, but making it an a-priori requirement seems counter-productive. Look at all the proposed formats first and then decide which one is most convenient. (E.g., RDF might be an alternative, or Windows resource file format, or RFC 2822 headers.) R21. Manifest independence COMMENT 21) Typo: "to" -> "from" in "An author may provide a copy of the manifest separately to the package." COMMENT 22) Is this necessarily the author's choice, or can a server also serve the manifest automatically? I expect the latter. E.g., the Jigsaw server understands JPEG/JFIF as a package format and is able to serve either the package its the metadata (XMP only for now). COMMENT 23) For this feature to be useful, it seems there is an implicit requirement R21a that there is a URL scheme (at least for "http:") that identifies the manifest of a given widget, e.g., by adding ";text/widget-manifest" at the end of the URL. R22. Scripting Interfaces for Accessing an Instantiated Widgets COMMENT 24) The text of this requirement seems to assume that the widget's programming language is an OOP language. But the WD doesn't aim to standardize the language (although it probably should, see comments 11 and 28). So either this requirement must be reformulated without reference to an object, or the WD should say that it standardizes the widget's programming language as well. R23. Scripting Interfaces for Accessing and Configuring Runtime Properties R24. Scripting Interfaces for Changing User Preferences COMMENT 25) Are R23 and R24 different? It's useful to stress the importance of the user's preferences in shaping the environment in which a widget runs, but maybe that is more like a clarification of R23. R25. Automatic updates COMMENT 26) The VM should, of course, only check for updates if the user wants it to. The "should" in this requirement needs a qualification to that effect. R26. Widget State Change Events COMMENT 27) The states and state transitions of a widget (and of its windows, if it has a GUI) can be different (and have different names) on different OSs: minimized, maximized, zoomed, iconized, docked, hidden, resized, moved, obscured, raised, focused, foreground process, background process, paused, killed.... The widget API should define a set of states and transitions that is a good match for all modern OSs. Probably it will have some states that never occur on certain OSs, and some states that are less rich than on some OSs. E.g., there may be only one state for both "docked" and "minimized," even though some OSs may distinguish those. R28. ECMAScript Compatibility COMMENT 28) (See also comment 11.) ECMAScript is a relatively well-known language among Web developers, so it makes some sense to select it as the standard widget language. On the other hand, it is far less developed than, e.g., Python, Ruby or Java. It has a well-developed library for handling HTML, but it has no file handling, no sockets, little math, no color management, no encryption and compression libraries, no forks, threads and semaphores, no time and date libraries... Does the WAF WG expect such libraries to be added (or to add them itself)? COMMENT 29) Accessibility is mentioned as a design goal, but not as a requirement. I think it is possible to require that widgets are accessible at various levels, e.g., keyboard access to graphical elements, screen reader access, and non-graphical UIs. (None of the proprietary widget systems mention by the WD currently separate the GUI from the functions, but I once wrote a system that did just that, so I believe it is possible. See my essays[1,2] for some ideas.) [1] http://www.w3.org/People/Bos/webapps-proposal.html [2] http://www.w3.org/People/Bos/webapps.html Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Wednesday, 28 February 2007 17:07:32 UTC