WidgetURIScheme

This wiki page is devoted to the Widget URI Scheme that is proposed as part of the WebApps WG's Widgets specifications.

The information in this page started from the Widget URI Scheme slide set that Marcos Caceres presented to the WebApps WG's Widgets group plus TAG members during the 20 October 2008 TPAC meeting in Mandelieu France.

A draft specification titled Widgets 1.0: URI Scheme has been created and will be formally published by the W3C.

For some more information about this scheme see Issue #16 - Do widgets need their own URI scheme? and the links within this issue.

This page is a Work In Progress and as such, is likey to change ...

Requirements

• hierarchical URI scheme (for DOM).
• does not expose the underlying file system (if any).
• must not address resources outside the widget resource via the URI scheme (even if URI scheme allows it).
• would not conflict with browsers.

The Candidates

The candidates follows and each one is elaborated one section below:

• file: (file://host/path/to/thing)
• Content-ID (cid:foo4*foo1@bar.net)
• http URI (http://engine/widget/path)
• widget URI (widget://widget/path/to/thing)
• tag URI (tag:some@author.com,2009-02-01:someWidget/path/to/thing)
• implementation detail

file: URI Scheme

• PROS
  • widely used
  • hierarchical

• CONS
  • can expose underlying OS*
  • no standard
  • conflicts (browsers & widgets)

cid: URI Scheme

The cid URI scheme is defined in RFC 2392.

• PROS
  • simplistic

• CONS
  • Not specifically hierarchical
  • Under-defined
  • MIME-based
  • obscure

http: URI Scheme

• PROS
  • well understood
  • engine becomes server

• CONS
  • engine becomes server
  • complex
  • overkill

widget: URI Scheme

• PROS
  • designed for requirements
  • does not address file system
  • simple and logical

• CONS
  • new scheme

tag: URI scheme

The tag URI scheme is defined in RFC 4151.

• PROS
  • Do not need to mint a new URI scheme
  • Provides way to uniquely identify a widget.
  • Can leverage config doc metadata when available (e.g. using email address to compose tag)
  • Can leverage URI general syntax for paths, so resources inside widgets can be easily addressed

• CONS
  • May rely on random values when not enough data is available to compose the tag (e.g., when there is no config file).
  • Does not support/conform to Unicode/IRIs
  • Does not define a resolution mechanism

RFC 2557 - thismessage

• See proposal from Larry Masinter; 28-May-2009
• See response from Robin Berjon; 15-June-2009
• RFC 2557