List of comments on “Widgets 1.0: Requirements” (dated 15 September 2008)

Quick access to

There are 3 comments (sorted by their types, and the section they are about).

typo comments

Comment LC-2131
Commenter: Eric <neric27@wanadoo.fr> (archived message)
Context: 1. Introduction
Not assigned
Resolution status:

(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2128: Krzysztof on 2nd LC
Commenter: (wrong string) Å„ski <1981km@gmail.com> (archived message)
Context: Document as a whole
assigned to Marcos Caceres
Resolution status:

(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2134
Commenter: Cyril Concolato <cyril.concolato@enst.fr> (archived message)
Context: R6. Addressing Scheme
assigned to Marcos Caceres
Resolution status:


It seems to me that Requirement 6 should be split into two requirements:
A. "A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime."
B. "A conforming specification MUST specify or recommend an addressing scheme to address individual widget instances."

For requirement A, I think that, given that the WG specifies a Packaging Format for Widget, it could define as well a Fragment Identifiers syntax for this package. This would have the advantage of separating/hiding the protocol used to retrieved the widget and therefore address the problem of "The addressing scheme MUST NOT expose the underlying file system (if any)". I think authors are also used to that mechanism and therefore would satisfy "The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed."

For requirement B, correct me if I'm wrong, but since the exact identifier of a widget instance can only be known at runtime, I don't see how an author can determine it declaratively as a URL before instantiation. So, the URL to the widget instance has to be created at runtime as well. Therefore, I imagine that there could be an API to do the following: querying the available widget instances, then requesting a URL (internal to the User Agent) to a particular widget instance and finally creating the final URL using the previous URL and appending a proper fragment identifier.

Therefore it seems to me that a new URI scheme is not necessary. Where is my reasoning wrong?



Marcos Caceres a écrit :
> Hi Mark,
> On Thu, Oct 9, 2008 at 6:00 AM, Mark Baker <distobj@acm.org> wrote:
>> On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>>> <snip>
>>>> Any hierarchical URI scheme would seem to be able to meet those
>>>> requirements. So why not, for the sake of argument, file:?
>>> Yes, file: might be ok. But where is the spec that defines file:? I
>>> can't find it.
>> Good question. At least twice during the past 15 years or so,
>> somebody's tried to write a spec for it, but both times that's ended
>> in failure (e.g.
>> http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought
>> it up only as an example, because it doesn't carry all that "network
>> resource" mental baggage that many people commonly associate with
>> schemes such as ftp or http. It's still possible to use it of course,
>> as long as the fuzzy areas are avoided.
> I see what you mean, the Hoffman draft above reads more like a "here
> is a list of what is wrong with file:" rather than a spec. And rfc1738
> has been obsoleted.
>> But I wonder whether the scheme really matters very much. What kind
>> of intra-package references do you expect to be able to resolve? Will
>> they all be relative, or will there be absolute ones? If it's just
>> relative references, then any hierarchical one will do, as the
>> consuming user agent can just mint their own base, be it an http URI,
>> a file URI, or otherwise.
> We use both relative and absolute URI references, and the base is
> derived from the i18n model we have introduced. The reason we don't
> want to allow vendors to mint their own is that there are potential
> security and privacy issues related to URI schemes such as file:. For
> instance, because Dashboard uses "file:" it is very easy for me to
> work out what the username and home directory of a user on MacOsX by
> simply picking up any DOM node that contains a dereferenced URI (eg.
> by examining an img's src, I get something like
> "file:///Users/marcos/Library/widget/Default.png").
> Personally, the solution I keep coming to is something like :
> widget-uri = "http://" widget-engine [":" instance-id] "/"
> package-name path-absolute ["#" fragment]
> Where widget-engine is something akin to using, say, "localhost", but
> uses some arbitrary string that identifies the engine (e.g.
> theFooEngine). The optional instance-id would be a string that
> uniquely identifies a widget instance for the purpose of cross-widget
> communication. However, I can foresee that there may be problems with
> thieving http's port semantics to uniquely identify an instance (so we
> leave this out until version 2). The scheme would only support GET
> requests. For example,
> http://theFooEngine/barWidget.wgt/index.html#welcome
> Kind regards,
> Marcos
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:46:07 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org