Re: [Widgets] URI Scheme revisited.... again

Hi Mark,

On Wed, Oct 8, 2008 at 4:28 PM, Mark Baker <distobj@acm.org> wrote:
> Marcos - IIRC, there was little or no support for a widget URI scheme
> in the discussion on www-tag.  Why are you continuing to move ahead
> with it?

Sorry Mark, I'm afraid that your recollection on this issue is wrong.
Firstly, I was not aware that the TAG dictated what Web Apps works on.
Secondly, the TAG is interested in solving this problem as much as we
are [1]. Thirdly, TAG members have requested time at TPAC to meet with
Web Apps to allow us to move forward on this issue  (if there was
little support, then why do they want to meet with us? [2]). Fourthly,
we continue to push for a URI scheme because we can't resolve DOM
nodes in widgets to nothing (and we see the use of the "file://"
scheme as bad (and not standardized) and "http://" as too complex for
V1). There is no way for us to ignore the URI issue, so we need help
in resolving it. Asking us to stop working on this is not an option.
However, if you can help us or point us in the right direction then
please do so!

> Note that you'll still have to get this past IANA who maintains the
> registry.  IANA uses a process specified in RFC 4395 which says;
>
>   The use and deployment of new URI schemes in the Internet
>   infrastructure is costly; some parts of URI processing may be
>   scheme-dependent, and deployed software already processes URIs of
>   well-known schemes.  Introducing a new URI scheme may require
>   additional software, not only for client software and user agents but
>   also in additional parts of the network infrastructure (gateways,
>   proxies, caches) [11].  URI schemes constitute a single, global
>   namespace; it is desirable to avoid contention over use of short,
>   mnemonic scheme names.  For these reasons, the unbounded registration
>   of new schemes is harmful.  New URI schemes SHOULD have clear utility
>   to the broad Internet community, beyond that available with already
>   registered URI schemes.
>
>  -- http://tools.ietf.org/html/rfc4395#section-2.1
>

We have evaluated other options and none seem suitable. However, I we
are always open to suggestions of schemes to investigate (so long as
they are in line with our packaging requirements; hence, no MIME
formats for version 1.0 please!).

The requirement for the URI scheme is as follows:

R6. Addressing Scheme

A conforming specification MUST specify or recommend an addressing
scheme to address the individual resources within the widget resource
at runtime. The addressing scheme MUST be able to address individual
widget instances, while potentially allowing widgets to address each
other. The addressing scheme MUST NOT expose the underlying file
system (if any) to the instantiated widget and an instantiated widget
MUST NOT be able to address resources outside the widget resource via
the addressing scheme. The addressing scheme SHOULD be one that web
authors would feel comfortable using or to which they are already
accustomed.

Motivation:
    Ease of use, compatibility with other standards, current
development practice or industry best-practice, and security.
Rationale:
    To allow resources to be resolved and normalized within DOM
attributes. To make it easy for authors to address and load resources
into their instantiated widgets, either declaratively or
programmatically. For example, addressing a resource via an IRI
reference (e.g. <img src="images/bg.png'/> where the src attribute
resolves to something akin to "widget://myWidget/images/bg.png"). To
disable access that could lead to potentially unsafe manipulation by
widget instances to the underlying file system (if any) or other
resources which are not instances of the same widget or resources
contained in the widget resource used to create the current set of
widget instances.


Kind regards,
Marcos

[1] http://www.w3.org/2001/tag/group/track/issues/61
[2] http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda
-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 8 October 2008 16:08:35 UTC