W3C home > Mailing lists > Public > public-appformats@w3.org > February 2007

[widgets-reqs] Comments on http://www.w3.org/TR/2007/WD-widgets-reqs-20070209

From: Bert Bos <bert@w3.org>
Date: Wed, 28 Feb 2007 18:06:04 +0100
To: public-appformats@w3.org
Message-Id: <200702281806.04270.bert@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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:06 UTC