This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8264 - Fix terminology for "resource", "representation", "retrieval"
Summary: Fix terminology for "resource", "representation", "retrieval"
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P1 major
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-11 21:07 UTC by Larry Masinter
Modified: 2010-10-04 14:56 UTC (History)
6 users (show)

See Also:


Attachments

Description Larry Masinter 2009-11-11 21:07:58 UTC
To understand the web, a reader will need to be familiar with other documents which establish terminology that this specification disagrees with. The documents describing URIs and HTTP are not just "authoritative documents",  they're the actual documents that are also necessary to read and understand how the web works. Defining and using different and inconsistent terminology is very confusing, and leads to the specification being unclear about essential processes. The result is also at odds with reality (since some resources have no representation and content-negotiated resources may have many). 

 RFC 3986 section 1.2.2 gives an overview of the relationship between "resource" and "representation" as well as "retrieval".

   When URIs are used within information retrieval systems to identify
   sources of information, the most common form of URI dereference is
   "retrieval": making use of a URI in order to retrieve a
   representation of its associated resource.  A "representation" is a
   sequence of octets, along with representation metadata describing
   those octets, that constitutes a record of the state of the resource
   at the time when the representation is generated.  Retrieval is
   achieved by a process that might include using the URI as a cache key
   to check for a locally cached representation, resolution of the URI
   to determine an appropriate access mechanism (if any), and
   dereference of the URI for the sake of applying a retrieval
   operation.  Depending on the protocols used to perform the retrieval,
   additional information might be supplied about the resource (resource
   metadata) and its relation to other resources.

This terminology is used and expanded in http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging. 


CHANGE PROPOSAL:

The editorial changes are, unfortunately, extensive, and will require looking at every use of "resource" and "file", as well as "fetch" and "fetching". 

To start with section 2.1, "resources", change this to reference RFC 3986 and define "resources, representations, and retrieval". 

Align the definitions with the HTTP specification.

(there are other definitions which also need alignment, including MIME type, content type; do those need separate bug reports?)
Comment 1 Michael[tm] Smith 2009-11-12 05:17:44 UTC
quoting Larry Masinter:
> To understand the web, a reader will need to be familiar with other documents
> which establish terminology that this specification disagrees with. The
> documents describing URIs and HTTP are not just "authoritative documents", 
> they're the actual documents that are also necessary to read and understand how
> the web works. Defining and using different and inconsistent terminology is
> very confusing, and leads to the specification being unclear about essential
> processes. The result is also at odds with reality (since some resources have
> no representation and content-negotiated resources may have many). 
> 
>  RFC 3986 section 1.2.2 gives an overview of the relationship between
> "resource" and "representation" as well as "retrieval".
> 
>    When URIs are used within information retrieval systems to identify
>    sources of information, the most common form of URI dereference is
>    "retrieval": making use of a URI in order to retrieve a
>    representation of its associated resource.  A "representation" is a
>    sequence of octets, along with representation metadata describing
>    those octets, that constitutes a record of the state of the resource
>    at the time when the representation is generated.  Retrieval is
>    achieved by a process that might include using the URI as a cache key
>    to check for a locally cached representation, resolution of the URI
>    to determine an appropriate access mechanism (if any), and
>    dereference of the URI for the sake of applying a retrieval
>    operation.  Depending on the protocols used to perform the retrieval,
>    additional information might be supplied about the resource (resource
>    metadata) and its relation to other resources.
> 
> This terminology is used and expanded in
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging. 
> 
> 
> CHANGE PROPOSAL:
> 
> The editorial changes are, unfortunately, extensive, and will require looking
> at every use of "resource" and "file", as well as "fetch" and "fetching". 
> 
> To start with section 2.1, "resources", change this to reference RFC 3986 and
> define "resources, representations, and retrieval". 
> 
> Align the definitions with the HTTP specification.
> 
> (there are other definitions which also need alignment, including MIME type,
> content type; do those need separate bug reports?)
> 

[no comment; just repeating description in order to get it echoed to public-html]
Comment 2 Michael[tm] Smith 2009-11-12 10:41:07 UTC
this seems to related to existing tracker issue 81:

http://www.w3.org/html/wg/tracker/issues/81
Comment 3 Maciej Stachowiak 2009-11-12 10:44:53 UTC
Pretty much a duplicate of bug 7687 but this seems to contain a Change Proposal, which should go to the wiki and/or the mailing list.
Comment 4 Ian 'Hixie' Hickson 2009-12-10 12:09:50 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: marking as rejected since this is now going through the issue tracking process, and that means (per the process) that this bug should have been marked WONTFIX or otherwise rejected by an editor.
Comment 5 Larry Masinter 2010-06-03 01:34:18 UTC
This was ISSUE-81, http://www.w3.org/html/wg/tracker/issues/81