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

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.
http://dev.w3.org/html5/decision-policy/decision-policy.html

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
  http://www.w3.org/html/wg/wiki/Resource_and_Representation_Terms
"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
+1/-1.

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