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
[EMAIL PROTECTED] 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
