Re: Gloss standard terminology for resource/representation (ISSUE-81 Change Proposal)

On Tue, 6 Apr 2010, Maciej Stachowiak wrote:
> On Apr 6, 2010, at 10:31 AM, Ian Hickson wrote:
> > 
> > Just out of interest, is there any particular reason why the proposal 
> > explicitly calls out the HTTP and URI specs rather than focusing on 
> > consistency with other W3C specs?
> 
> What practical difference would it make to focus on consistency with 
> other W3C specs?

Well other specs don't talk about what "resource" means, they just use the 
term (like HTML5 does). I'm just curious about why HTML5 should be treated 
differently here than other W3C specs.


On Tue, 6 Apr 2010, Dan Connolly wrote:
> > > 
> > > Do you mean other W3C data format specs, such as CSS? There wasn't 
> > > while I was preparing it, but now that I think about it: I don't 
> > > think other W3C data format specs try to define the terms "resource" 
> > > and "representation". They import the terms from the URI spec.
> > 
> > They don't define the term, but they use it the same way as HTML5.
> 
> I accept that as your opinion. I don't agree.

This isn't really a matter of opinions, it's a testable assertion.

| ...the instance data is formed by creating an XPath data model of the 
| linked resource.
|
| ...to place the filename for the chosen binary resource.
|
| ...to place the mediatype of the chosen binary resource, if available.
|
| Factoring all human readable messages to a separate resource XML file.
| Using URIs into this XML resource bundle within individual label 
| elements
|
| ...could use content negotiation to obtain the appropriate XML resource 
| bundle...
 -- http://www.w3.org/TR/2009/REC-xforms-20091020/

| ...an SVG document (i.e., a Web resource whose MIME type is 
| "image/svg+xml")...
|
| An SVG document fragment can stand by itself as a self-contained file or 
| resource...
|
| Many resources, especially media such as audio and video, have a wide 
| range of formats.
|
| It gives authoring tools and authors the ability to schedule retrieval 
| of resources...
 -- http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/single-page.html

| This attribute specifies the content type of the resource designated by 
| the value attribute...
|
| Choosing between audio resources with different bitrates
|
| Choosing between audio resources in different languages
|
| This element will give a suggestion or hint to a user agent that a media 
| resource will be used in the future and the author would like part or 
| all of the resource fetched ahead of time to make the document playback 
| smoother.
|
| Defines how much of the resource to fetch as a function of the file size 
| of the resource.
 -- http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil30.html

| An unparsed entity is a resource whose contents may or may not be text, 
| and if text, may be other than XML.
|
| ...the URI of the resource retrieved after all redirection has 
| occurred.
 -- http://www.w3.org/TR/2008/REC-xml-20081126/

| ...if the resource being signed encloses the signature itself...
|
| ...the meaning of the fragment is defined by the resource's MIME type.
|
| Whether this instantiates in-line processing of local XSLT declarations 
| within the resource is determined by the XSLT processing model...
|
| Occasionally we refer to a data object as a document or as a resource's 
| content.
 -- http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/

| ...the syntax of a class of resources called XML documents...
 -- http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/

| ...as if that resource had no intrinsic dimensions.
|
| The URI must designate an auditory icon resource.
 -- http://www.w3.org/TR/2009/CR-CSS2-20090908/css2.txt

| The document node is the root of a tree that represents that resource 
| using the data model.
 -- http://www.w3.org/TR/2007/REC-xquery-20070123/

| ...can be used to identify an RDF resource that describes the role in 
| more detail.
|
| Specifies the limited context in which the resource should be presented 
| if the external destination is a resource of a processed structured 
| media type for which a limited presentational context makes sense (e.g., 
| XML, XHTML, SVG).
 -- http://www.w3.org/TR/2006/REC-xsl11-20061205/

| It resolves to (a fragment of) a resource which is an XML document 
| (of type application/xml or text/xml with an XML declaration for 
| preference, but this is not required)...
|
| For interoperability, serialized schema documents, like all other Web 
| resources, may be identified by URI and retrieved using the standard 
| mechanisms of the Web (e.g. http, https, etc.)
|
| Based on the location URI, identify an existing schema document, either 
| as a resource which is an XML document...
 -- http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

That's not even quoting the many occurances of the terms "external 
resource" and "subresource" which would be tautological if the term 
"resource" was being used as the URI and HTTP specs use it.


> > > Another motivation for calling out HTTP is that the distinction 
> > > between the URI/resource/representation world-view and the 
> > > URL/resource world-view is tangible there; when discussing multiple 
> > > HTTP transactions based on a URI, it makes sense to speak of one 
> > > thing that the URI identifies across them.
> > 
> > What does it identify? The script on the server? I can see a need for 
> > a term for use in abstract discussions, but in the concrete world of 
> > the implementable specs, there doesn't seem to be any need. It's just 
> > bits on the wire -- a URL turns into an HTTP request which turns into 
> > a bag of bits with headers and data... there's no need to talk about 
> > the server- side script, even, let alone the abstract concept of that 
> > script.
> 
> Whether you see a need or not is not relevant to this proposal; the fact 
> is: there are previously ratified specs that use the 
> URI/resource/representation model, and they are cited by the HTML 5 
> spec. Some explanation of the difference in terminology is in order.
>
> As editor, your opinion is relevant to the wholesale use of terminology 
> in the spec, but I don't propose to change that. I only propose that the 
> spec provide some explanation of the difference between your preferred 
> terminology and the previously ratified terminology.

I believe that mentioning such differences will increase the level of 
confusion, not reduce it, because few people are familiar with the way 
HTTP uses these terms.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 6 April 2010 19:10:24 UTC