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