Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
widget URI scheme that is used to address resources
inside a widget package [WIDGETS].
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 published by the Web Applications WG as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives). The Last Call period ends 10 November 2009. All feedback is welcome.
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.
This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.
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 section is non-normative.
Resources inside a widget package are identified and located using a method that is specific to widgets technology. Widget URIs reflect this by providing these specific locators with their own syntax so that resources in widget packages can be readily identified.
In general, authors of widget content use relative URI references. Widget URIs are therefore primarily synthesised by the user agent as it absolutises URI references found in documents contained in widgets packages.
There are many different efforts specifying URI schemes to access the content of Zip archives and formats based on Zip, or endeavour to do so. While these efforts have merit, and while W3C Widgets is one such format, the use cases that this specification addresses are substantially different: rather than identify packaged resources from the outside, widget URIs identify them only on the inside of a package, irrespective of that package's own location. 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.
Uniquely identifying widgets, or multiple instances of the same widget package, as well as enabling inter-widget communication are also outside the scope of this document.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].
There are three classes of products that can claim conformance to this specification:
Throughout this specification, wherever the term URI [URI] is used, it can be replaced interchangeably with the term IRI [RFC3987]. All widget URIs are IRIs, but the term URI is more common and was therefore preferred for readability.
Widget URIs are URIs as per [URI] and [RFC3987], with specific aspects described in the following sections.
A valid widget URI must adhere to the IRI grammar rule
from [RFC3987], and its scheme component must be the
case-insensitive string "widget".
A valid widget URI reference must adhere to the IRI-reference grammar rule from [RFC3987], and if it is an absolute URI reference then it must be a valid widget URI.
A producer must generate URIs that are normalised according to chapter 5.3.2. "Syntax-Based Normalization" of [RFC3987].
A consumer must be able to parse any valid widget URI.
Note that assigning semantics or interpretation to the query or fragment components is outside the scope of this specification. The ways in which they are used depends on the content types that they are applied to, or what executable script decides to do with them.
Example widget URIs could thus be:
widget://beefdead/dahuts/sightings/alpes-françaises.svg
(assuming the generated opaque authority is beefdead) or
widget:///secret-identities/marcoscàceres/batman.foaf if there is no
authority component.
A producer may include an authority component in URIs. If present, the authority component is said to be opaque, meaning that the authority component has a syntax as defined by [RFC3987] but that the authority component is devoid of semantics.
A consumer should ignore the authority component, when present.
When computing the base URI for a resource contained in a widget package
a producer must concatenate widget://, optionally
the opaque authority, the U+002F SOLIDUS (/) character, and the
Zip relative path to the
resource.
When resolving a relative URI references against a base URI, a consumer must use the mechanism defined in chapter 5.2. of [URI].
Note that using widget URIs directly when authoring content is discouraged, and authors should stick to using schemeless relative URI references.
To resolve a widget URI to a resource within a given widget package a consumer must apply the following algorithm (or one that guarantees the same result):
In some contexts one needs to map a URI into an origin, for instance in the [HTML5] HTML5 origin algorithm.
Mapping from a widget URI to an origin takes place as follows:
widget.null.
This section is non-normative.
dahuts/dextrogyrous.html features a link to levrogyrous.html
that link must resolve to dahuts/levrogyrous.html.
This section is non-normative.
The following people were instrumental in producing this specification:
Art Barstow, Marcos Caceres, Thomas Roessler, Larry Masinter, Marcin Hanclik, Mark Baker, and Jere Kapyaho.