Many specifications in the Web stack depend on a context being defined that includes a current URI. This is easily provided for documents retrieved over HTTP, or from the local file system, but is currently undefined for documents extracted from within a widget package. Such a limitation has a number of implications which this document intends to address.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This is the 18 June 2009 First Public Working Draft version of the "Widgets 1.0: URI Scheme" specification. The purpose of this draft is to give external interested parties an opportunity to publicly comment on a URI scheme for use inside widgets or other such applications of web technology that do not run on the web.
This document is produced by the Web Applications WG, part of the Rich Web Clients Activity in the W3C Interaction Domain. It is expected that this document will progress along the W3C's Recommendation track. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
You can find the latest Editor's Draft of this document in the W3C's CVS repository, which is updated on a very regular basis. The public is encouraged to send comments to the Web Apps Working Group's public mailing list firstname.lastname@example.org (archive). See W3C mailing list and archive usage guidelines. A detailed list of changes from the previous version is also available from the W3C's CVS server.
Implementers should be aware that this document is not stable. Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this document before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.
Note: User agents that wish to extend this specification in any way are encouraged to discuss their extensions on a public forum, such as public-webapps so their extensions can be considered for standardisation.
This specification defines the
widget URI scheme for use
inside widgets or other such applications of web technology that do not
run on the web.
There are many different efforts that have specified URI schemes to access the content of Zip archives, or endeavour to do so. While these efforts have merit, and while W3C Widgets rely on Zip as a packaging format, the use cases that this specification addresses are radically different. In fact, it is possible that both this scheme and another defined to access Zip archive content would be used jointly, with little or no overlap in functionality.
The scheme defined in this specification could be used to implement inter-widget communication, but that is outside the scope of this current document.
dahuts/dextrogyrous.htmlfeatures a link to
levrogyrous.htmlthat link must resolve to
A careful review of existing schemes has found that none matches the needs above.
widget URI scheme
is primarily intended for usage with URIs that are synthesised by the user
agent as it absolutises URI references found in documents contained in
widgets or defines base URIs for them.
Note: Note that using widget URIs directly when authoring content is discouraged, and authors should stick to using schemeless relative URI references.
As a widget is initialised the user agent may generate an identifier that will be used as the authority part of the widget absolute URI. As of this specification that identifier has no semantics and must be ignored while resolving the URI reference to a representation. If present, the authority will be said to be opaque. Future versions of this specification may define more precise syntax and semantics for this opaque authority.
The ABNF syntax [ABNF] for widget URIs is as follows:
widget-URI = "widget:" "//" [ authority ] "/" zip-rel-path [ "?" query ] [ "#" fragment ]
zip-rel-path non-terminal is defined in the Widgets 1.0: Packaging
and Configuration specification [Widgets-PC]
and the others reference RFC 3986 [URI].
Example widget URIs could thus be:
The base URI for a resource contained in a widget is constructed by
widget://, optionally the opaque authority, and
relative path to the resource.
Resolution of relative URI references is performed using the mechanism appropriate for the language in the context of which the reference appears, typically following chapter 5 of [URI] or possibly [HTML5].
Mapping from a widget URI to an origin is depends on the rules defined for this purpose by the document type being referenced.
Within an HTML 5 context [HTML5], the origin of a
resource inside a widget is defined by an extension to the HTML5 origin algorithm. If
component obtained after step 5 is
widget, then the tuple
that is returned is "
widget", optionally the opaque authority
part, and nothing for the <port> component.
Furthermore, the ASCII and Unicode serialisations for widget origins are
as defined in HTML 5 for other schemes, except that the port is always
considered to be the default one for the given protocol.
The process of resolving a widget URI to a resource within a given widget is as follows:
Note that neither the query nor the fragment parts of the widget URI are used in the resolution process. They must nevertheless be kept as part of the URI and processed according the rules defined by the content type being referenced.
The following people were instrumental in producing this specification:
Art Barstow, Marcos Caceres, Thomas Roessler, Larry Masinter, and Jere Kapyaho.