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

Bert,

Thanks very much for your excellent comments! It is going to take us  
some time to adresss all of them.

As I mentioned in a separate thread on this list, the document,  
particularly section 1.1.2 is a bit confusing because it enumerates  
several facets of Widgets that *could* be standardized. However, some  
of those facets are not in the WAF WG's scope (as defined by WG's  
Charter). For instance "APIs for device services" is not within this  
WG's scope. However, such APIs could be within the scope of the Web  
API WG as well as the DI/UWA WG. Likewise, those types of APIs also  
appear to be in scope for OMA's Device Profile Evolution [DPE] work.

Anyhow, I expect the next Draft to clarify those aspects of Widgets  
that in and out of scope for the WAF WG.

Regards,

Art Barstow
---

[DPE] <http://www.openmobilealliance.org/release_program/rd.html>


On Feb 28, 2007, at 12:06 PM, ext Bert Bos wrote:

>
> 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 Thursday, 8 March 2007 22:47:55 UTC