View source

From WEBAPPS

You do not have permission to do that, for the following reasons:

• The action you have requested is limited to users in one of the groups Sysops, webappsEditors.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

This wiki page is devoted to the ''Widget URI Scheme'' that is proposed as part of the WebApps WG's [http://www.w3.org/2008/webapps/wiki/Main_Page#Widgets Widgets specifications]. The information in this page started from the [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/att-0299/TPAC_URISchemes.pdf Widget URI Scheme slide set] that Marcos Caceres presented to the WebApps WG's Widgets group plus TAG members during the [http://www.w3.org/2008/10/20-wam-minutes.html#item12 20 October 2008 TPAC meeting] in Mandelieu France. A draft specification titled [http://dev.w3.org/2006/waf/widgets-uri/ Widgets 1.0: URI Scheme] has been created and will be formally published by the W3C. For some more information about this scheme see [http://www.w3.org/2008/webapps/track/issues/16 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 [http://tools.ietf.org/html/rfc2392 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 [http://www.rfc-editor.org/rfc/rfc4151.txt 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 [http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0642.html proposal from Larry Masinter]; 28-May-2009 * See [http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0972.html response from Robin Berjon]; 15-June-2009 * [http://www.rfc-editor.org/rfc/rfc2557.txt RFC 2557]

Return to WidgetURIScheme.