W3C home > Mailing lists > Public > public-html@w3.org > April 2010

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

From: Dan Connolly <connolly@w3.org>
Date: Tue, 06 Apr 2010 15:50:29 -0500
To: Ian Hickson <ian@hixie.ch>
Cc: Maciej Stachowiak <mjs@apple.com>, public-html@w3.org
Message-ID: <1270587029.4466.2874.camel@pav.lan>
On Tue, 2010-04-06 at 19:09 +0000, Ian Hickson wrote:
> 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.

I'm not asking for HTML 5 to be treated differently;
I've made similar comments in the case of other 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.

Thanks for the data.

It seems to be quite a number of testable assertions, some of
which look more like the URL/resource model and some
of which look more like the URI/resource/representation model.

> | ...the instance data is formed by creating an XPath data model of the 
> | linked resource.

That's consistent with both views. In one model, creating an XPath
data model involves fetching a representation of the
linked resource; in the other, the resource is what's fetched.

> | ...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")...

That one is only consistent with the URL/resource model.

> | An SVG document fragment can stand by itself as a self-contained file or 
> | resource...

That's consistent with both models; a URI can identify a
resource that is an SVG document which has a representation
that is also and SVG document.

> | Many resources, especially media such as audio and video, have a wide 
> | range of formats.

That use is only consistent with the URI/resource/representation model.

> | It gives authoring tools and authors the ability to schedule retrieval 
> | of resources...

That use is consistent with both; "retrieval of resources" is
short for "retrieval of representations 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...

That presumes the resource has just one content type, but it works
with both models.

> | Choosing between audio resources with different bitrates
> |
> | Choosing between audio resources in different languages

Those are only consistent with the URL/resource model.

> | 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.

That's more consistent with URL/resource, though it's not _that_ much
of a stretch to take "part or all of the resource" to mean
"part or all of a representation of the resource".

Perhaps I'll find time to look closely at the other examples you gave,
but my point is already made: some use is consistent only with one
model, some only with the other, and many are consistent with both.

> > 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.

Few relative to the population of the planet, yes... even relative
to the web development community as a whole perhaps. But relative to the
intended audience of this spec, especially sections such as
the one on Application caches, I believe they are a
critical constituency, if not the majority.

I gather we're at step 3, Discussion in the escalation process.

I'd like to hear from other people.
I'm interested to know if this proposal has "wide support".

In the interest of gauging support/opposition, I created
"This page is one way to express support or opposition to the Gloss
standard terminology for resource/representation change proposal re
ISSUE-81, rather than using n^2 email messages whose content is only

Please send novel arguments to the public-html mailing list; feel free
to cite them here, but make sure to send them there."

Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Tuesday, 6 April 2010 20:50:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:46 UTC