Edit comment LC-2304 for Web Applications Working Group

Quick access to LC-2301 LC-2302 LC-2303 LC-2304 LC-2305 LC-2306 LC-2307 LC-2308 LC-2309 LC-2310

Comment LC-2304

Comment Shortname:

Commenter: Larry Masinter <masinter@adobe.com>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeWidgets 1.0: Widget URIs /**/ /************************... Abstract This specification defines the widget URI scheme t... Status of This Document This section describes the status o... Table of Contents 1. Introduction 1.1 Not in this specif... 1. Introduction This section is non-normative. Resources in... 1.1 Not in this specification There are many different effo... 2. Conformance As well as sections marked as non-normative,... producers consumers valid widget URIs 3. Definitions Throughout this specification, wherever the... URI 4. Widget URIs Widget URIs are URIs as per [URI] and [RFC39... Widget URIs 4.1 Syntax A valid widget URI must adhere to the IRI gramma... 4.2 Authority A producer may include an authority component... opaque 4.3 Base URI and Relative URI Reference Resolution When com... 4.4 Mapping widget URIs to files within a widget package To... A. Usage as Origin In some contexts one needs to map a URI... B. Requirements This section is non-normative. Must allow... D. References D.1 Normative references [RFC2119] S. Bradn... D.1 Normative references [RFC2119] S. Bradner. Key words f... [RFC2119] [RFC3987] [URI] [WIDGETS] D.2 Informative references [HTML5] Ian Hickson; David Hyat... [HTML5]
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

3) ** Reuse URI schemes **

http://www.w3.org/TR/webarch/#URI-scheme includes "Good practice: Reuse URI schemes"

"A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources."

The draft suggests there are many other schemes (with merit) already proposed, but that these existing efforts, "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.", but this seems to indicate that the requirements for "widget" URIs are weaker, not stronger.

Suggestion: Supply use cases where reuse of existing schemes (including "thismessage:/") do not provide the desired properties of identifiers and their relation to resources.
Alternate Suggestion: Withdraw registration of "widget:" and reference existing scheme.
Alternate Suggestion: Provide guidelines so that "widget:" can be used for other applications
that need a way of referencing components within ZIP packages; rename "widget:" to use
a scheme name that is appropriate for this broader application.

AWWW Suggestion: add guideline: "Make New URI Schemes Reusable If You Can't Reuse URI schemes".

Related issues: (space separated ids)

WG Notes:

Resolution:

(Please make sure the resolution is adapted for public consumption)