This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?)
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]
this seems to related to existing tracker issue 81: http://www.w3.org/html/wg/tracker/issues/81
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.
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.
This was ISSUE-81, http://www.w3.org/html/wg/tracker/issues/81