Change Proposal UriDefinitionDiscoveryProtocol

From W3C Wiki

Change Proposal: URI Definition Discovery Protocol

This is an httpRange-14 change proposal prepared in response to the TAG's Call for proposals to amend the "httpRange-14 resolution"

Editor and submitter: David Booth <david@dbooth.org>

 

Summary

Describe the change in approximately one to five paragraphs of plain language.

This change proposal is written as a protocol specification (see URI Definition Discovery Protocol[uddp]) that enables a URI owner to provide a definition for a target URI that uses the “http” or “https” scheme, such that a client agent starting with that target URI can easily discover the URI owner's definition. Highlights:

  • It enables a URI owner to unambiguously convey any URI definition to an interested client.
  • It also allows non-URI owners to publish conflicting or complementary definitions, and allows them to refer by URI to each other's definitions.
  • It does not constrain whether or how a client must use that or any other URI definition, as that is the client's business.
  • It retains the intent of the existing httpRange-14 rule.
  • It also permits the use of an HTTP 200 response with RDF content as a means of conveying a URI definition.
  • It provides guidelines for avoiding confusion and inconsistencies, while acknowledging the burden those guidelines place on URI owners.
  • It encourages URI owners to publish URI definitions even if those URI definitions are not perfect.

It also includes numerous other clarifications.

Rationale

Describe the reason for the change. What problems does the proposal address, and how does the proposal makes things better?

  • The baseline document[baseline] expands the scope of the httpRange-14 resolution to cover URI schemes other than "http" and "https", attempting to address additional problems that exist in theory but not in practice, and this causes it to be vague and harder to apply than necessary. In contrast, this proposal[uddp] is limited to the original scope of the httpRange-14 issue. Limiting the scope allows the document to be clearer, more concrete and easier to understand and apply. It will also allow future work on the document to be more focused and proceed faster.
  • The baseline document fails to distinguish between a URI definition and other information involving the target URI. This proposal makes this distinction clear.
  • This proposal frames the problem differently and defines terms differently, thereby simplifying the issue and bypassing rat holes such as:
    • whether or not transmitted information actually "documents the intended meaning of a particular probe URI";
    • whether a representation actually does carry URI documentation that "bears on the meaning of that URI";
    • whether or not a representation "contains the URI documentation" and whether or not "the documentation occurs unqualified";
    • what constitutes the "meaning" of a URI, or the "determination of URI semantics";
    • whether a particular URI definition is "authoritative" in any global or legal sense.
  • This proposal, framed as a protocol specification, also clarifies several things that the baseline document leaves unclear, including:
    • what are the exact responsibilities of the URI owner and client;
    • exactly what information a URI owner considers to be a URI definition of a target URI;
    • exactly what URI definition is implied by an HTTP 200 response; and
    • what it means for a URI owner to provide multiple URI definitions for a target URI.

Finally, some issues are much more subtle, but again are reflected in the way the baseline document frames the problem:

  • The baseline document seems to make the implicit assumption that if it calls something a URI "definition", then clients will be obligated to use that and only that definition. This proposal calls a spade a "spade", but makes clear that clients may use or ignore a URI definition as they see fit.
  • The baseline document seems to make the implicit assumption that a URI has, can have, or should have, a unique, universally agreed, referential meaning, and that this is architecturally important to the semantic web. This proposal supports the semantic web by enabling certain URI definitions to be algorithmically discovered, without making such untenable assumptions.

Details

Use one of the following ways to provide the specifics of your proposal:

  1. A set of edit instructions, specific enough that they can be applied without ambiguity.
  2. Spec text for a draft to be published separate from HTML5 (though such a draft can be proposed at any time without a Change Proposal).
  3. Exact spec text for the sections to be changed, and a baseline revision for the version of the spec being changed.
  4. With prior permission from the chairs, a high-level prose description of the changes to be made.

The proposed URI Definition Discovery Protocol is located at http://www.w3.org/wiki/UriDefinitionDiscoveryProtocol and contains too many changes from the baseline document[baseline] to productively list them individually. It should be read and considered as an entire replacement of the baseline document, while also considering individual ideas that it contains. Basic reasons for writing it as a single, cohesive document:

  • It is much easier to read than a long list of individual changes.
  • The baseline document contains some significant framing issues that pervade the document. These may appear to some to be insignificant editorial differences, but they are not, as they bias the reader's perception of the problem and thus bias the solution space.

Impact

The proposal draws a balance between endorsing and dramatically clarifying the current httpRange-14 rule, while enabling and encouraging the publication of detailed URI definitions.

Positive Effects

List advantages

  • The proposal much more clearly specifies how a URI owner can convey a URI definition to an interested client.
  • It clearly specifies what constitutes a URI definition conveyed under this protocol.
  • It does not constrain whether or how a client must use that or any other URI definition.
  • It does not constrain the form, format or content of a URI definition.
  • It retains the existing httpRange-14 rule, thus allowing URI owners to conveniently indicate a implicit URI definitions of their URIs and retaining compatibility with existing billions of URIs.
  • It also permits the use of an HTTP 200 response with RDF content as a means of conveying a URI definition, thus endorsing a means of providing a URI definition that is, in some cases, less burdensome to URI owners that using hash URIs or 303 redirects.
  • It provides guidelines for avoiding confusion and inconsistencies, while acknowledging the burden those guidelines place on URI owners.
  • It encourages URI owners to publish URI definitions (even if those URI definitions are not perfect).

Negative Effects

List disadvantages

Several of the above advantages can also be legitimately viewed as disadvantages.

  • The proposal does not constrain whether or how a client must use that or any other URI definition. Some, who wish to impose a global notion of authoritative URI definitions, may find this a disadvantage.
  • It does not constrain the form, format or content of a URI definition. This means that there is no guarantee that a URI definition will be usable or useful to a client.
  • It retains the existing httpRange-14 rule. This may be seen as a disadvantage to those who do not want an HTTP 200 response to imply anything about the nature of the target resource.
  • It permits the use of an HTTP 200 response with RDF content as a means of conveying a URI definition. This adds complexity to clients that wish to discover URI definitions.
  • It does not prevent a URI owner from publishing multiple, conflicting URI definitions.
  • It does not specify how a client can obtain URI definitions other than those provided by URI owners.

Conformance Classes Changes

Describe what conformance classes will have to change.

I do not know what this means, but AFAICT it is not relevant.

Risks

Risks are described in section 4 "Avoiding and resolving inconsistencies".

References

Other references are listed directly in the specification[uddp].