headers
Marcos Caceres | 2 May 2007 06:53
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209


Hi Bert,
Members of the working group took time during our recent face-to-face
meeting to discuss and address the comments you sent us (see April
17th minutes [1]).
I the hope of generating further discussion about the requirements for
the widget spec, I have split my responses to your comments into
multiple emails. Also, I have omitted comments marked as typos and
some comments that were editorial in nature. Editorial issues you
pointed out have been addressed in the latest editor's draft of the
Requirements document [2]. Thank you again for your thorough review of
the document.

> 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.

To be able to mandate that complete widget functionality be available
on all devices would require that we specify a complete solution for
widgets. So far, we have focused mainly on packaging, bootstrapping,
and a base APIs. The working group feels it is beyond the scope of the
charter to specify a complete solution for widgets. We have
deliberately avoided mandating requirements of the UIDL because of the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Marcos Caceres | 2 May 2007 06:54
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


This is a response to Bert Bos' review [1] of the Widgets 1.0
Requirements document [2].

> 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?

Not true – if a Java applet was packaged to conform with the Widget
1.0 specification then that Java applet would be a conforming widget.
The same holds true for Flash files,.exe files, or any other binary
format. Secondly, we agree that a Java VM is more than capable of
running a widget (hence, you can of course create a widget engine on
top of the Java VM) and we feel that there is little distinction
between widget engines implemented in Java or any other language. We
will try to make this clearer in the specs.

As an aside, you raise a point that we seem to be continuously
encountering: that is, what exactly is a widget? In technical terms,
the widget specification will probably define a widget as a packaged
collection of files that may include an optional manifest file capable
of being extracted and instantiated on a widget engine. The definition
itself does not speak of functionality/experience afforded by a
widget. I guess widget engine is any software capable of extracting,
processing, and presenting a conforming widget package. We don't
expect our definition of a widget to match a user's experience or
definition of a widget.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Marcos Caceres | 2 May 2007 06:54
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


This is a response to Bert Bos' review [1] of the Widgets 1.0
Requirements document [2].

> 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.)

The text of section 3.2 has been updated to include the word
"metadata". It now reads: "The manifest language would generally allow
authors to declare metadata and other properties related to their
widget, as well as provide a means to automatically instantiate the
widget"

--

-- 
Marcos Caceres
http://datadriven.com.au

[1] http://lists.w3.org/Archives/Public/public-appformats/2007Feb/0131.html
[2] http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/
Permalink | Reply | 501 comments |
headers
Marcos Caceres | 2 May 2007 06:55
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


This is a response to Bert Bos' review [1] of the Widgets 1.0
Requirements document [2].

>   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.

We have yet to evaluate the appropriateness of any of those
technologies listed to what is actually used in the wild (eg. I have
not seen any widgets use CC/PP or make effective use of Media
Queries). As you have suggested, there are currently a number of
working groups looking at the issue of APIs for accessing device
services/capabilities. We currently feel that specifying APIs that
access services on devices are out of scope for WAF but will continue
to monitor what other groups are doing (particularly those at the W3C
and OMA in regards to Delivery Contexts).

--

-- 
Marcos Caceres
http://datadriven.com.au

[1] http://lists.w3.org/Archives/Public/public-appformats/2007Feb/0131.html
[2] http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/
Permalink | Reply | 503 comments |
headers
Marcos Caceres | 2 May 2007 06:55
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


This is a response to Bert Bos' review [1] of the Widgets 1.0
Requirements document [2].

> 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?

"Currently" refers to APIs of the widget engines we investigated in
order to put the requirements document together (see Appendix). I have
created a new section in the Appendix of the requirements document to
more fully discuss the APIs available on current widget engines. This
sections is currently empty and I will attempt to fill in the next
month or so. For the record, we are not planning to extend the
requirements to anything other than widgets.

--

-- 
Marcos Caceres
http://datadriven.com.au

[1] http://lists.w3.org/Archives/Public/public-appformats/2007Feb/0131.html
[2] http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcos Caceres | 2 May 2007 06:55
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


This is a response to Bert Bos' review [1] of the Widgets 1.0
Requirements document [2].

>   1.1.2. Standardizable Aspects of a Widget
<snip>
> 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.

To the list of standardizable aspects I have now added: "A
pre-existing scripting language to provide widgets with functionality
along with a set of language-independent programmable interfaces that
could be implemented by widget engines and made available to widgets
at runtime" and "a pre-existing language to declare the user
interface." However, these will be marked as open issues. Although
these are identified as standardizable aspects, we make no commitment
at this point to standardising them in the Widgets 1.0 spec.

> 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).

True, specifying a complete solution for writing widgets would solve
the mutual compatibility problem but might make the specification
completely incompatible with every widget engine in the wild (however,
because of fragmentation in the widget space, I acknowledge this may
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcos Caceres | 2 May 2007 06:55
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


> 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.

Agreed. Widget encryption has been removed as a requirement. Authors
are free to encrypt packages using whatever means they have at their
disposal, but they will need to be decrypted before they can be run on
a widget engine. We make no requirement on widget engines to support
encryption (even if the packaging format supports it).

--

-- 
Marcos Caceres
http://datadriven.com.au
Permalink | Reply | 0 comments |
headers
Marcos Caceres | 2 May 2007 06:56
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


This is a response to Bert Bos' review [1] of the Widgets 1.0
Requirements document [2].

>   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.)

The design decision to use XML is based on what is currently
implemented in the widget engines we reviewed (please see Appendix of
Requirements document).

--

-- 
Marcos Caceres
http://datadriven.com.au

[1] http://lists.w3.org/Archives/Public/public-appformats/2007Feb/0131.html
[2] http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/
Permalink | Reply | 0 comments |
headers
Marcos Caceres | 2 May 2007 06:56
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


This is a response to Bert Bos' review [1] of the Widgets 1.0
Requirements document [2].

>   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.

The focus of this design goal was for the benefit of both vendors and
users. We feel that having them as separate design goals emphasizes
our commitment to using other standards AND making things as easy to
use as as possible for everyone (particularly for developers that
would need to work with the spec).

--

-- 
Marcos Caceres
http://datadriven.com.au

[1] http://lists.w3.org/Archives/Public/public-appformats/2007Feb/0131.html
[2] http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/
Permalink | Reply | 0 comments |
headers
Marcos Caceres | 2 May 2007 06:56
Picon
Picon
Favicon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209)


This is a response to Bert Bos' review [1] of the Widgets 1.0
Requirements document [2].

> 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.

I don't understand why this is going too far? In terms of metadata,
there is also a lot of variation in what widget vendors ask their
developers to provide. We want to standardise this based on industry
best practices (like JavaDoc) and also address the needs of
developers. The requirement is not meant to imply that it is mandatory
that a developer actually provide those details for a widget. So,
unless I've misunderstood your point, from my perspective I really
don't see why giving developers a set of elements in which to record
information about the widget is going too far?

> Maybe it should be a requirement that the widget package has space for
> free-form comments, e.g., a README file.

I have modified R12 to read: "This metadata may include details like
the name, email, and IRI of the author(s) that created the widget or
even a free-form comment container where an author can include, for
example, something similar to a 'README' file".

--

-- 
Marcos Caceres
http://datadriven.com.au
(Continue reading)

Permalink | Reply | 0 comments |

Gmane