Re: Approved TAG finding: On Linking Alternative Formats

On Wed, 2006-11-01 at 11:51 +0100, Vincent.Quint@inrialpes.fr wrote:
> All,
> 
> The W3C Technical Architecture Group (TAG) has approved yesterday the finding
> On Linking Alternative Formats To Enable Discovery And Publishing:
> 
>     http://www.w3.org/2001/tag/doc/alternatives-discovery.html

Hi Vincent and Raman,

Thank you for publishing this document. I just enjoyed reading it.
I have a couple of minor comments. Thank you,

 - Ian

1) In the intro: "the relation between these multiple representations 
   needs to be captured by the hyperlink structure of the Web."

   I think I understand, and yet it seems to me that one could also
   argue in favor of making relationships known through protocol 
   metadata.
 
   If I understand correctly, one suggestion is to represent 
   relationships in representations (e.g., through the LINK element).
   If I discover relations by examining a representation, that means
   that all the alternatives need to inclue all the information about
   the others in the set. This is likely to be difficult to manage, 
   especially for more than a few related resources. 

   Assuming the TAG has considered the alternative of making 
   relationships known through protocols, I think it might be valuable
   to compare the two approaches: relationships expressed in 
   representations v. relationships expressed in protocol metadata.

   This also seems related to issue siteData-36 [1].

   I have not followed discussions on this finding; if this ground has
   been covered I'm happy to read the archive.

2) In section 2.1.1 [2], bullet four starts "As an alternative to the 
   previous step,..." There is some comparison of the two approaches
   in that bullet (VARY v. HTTP 302), but I think the text could be
   clarified so that one understands better when to use one approach
   or the other, or it really doesn't matter architecturally which
   you choose.	

   One editorial way to address this is to merge bullets 3 and 4 into
   a single bullet that talks about how to configure the server to
   serve alternatives, describing the two approaches, and then
   comparing the two aproaches. 

3) Sections 3 and 4 say "URIs are cheap; we suggest creating as many
   distinctive URIs as is meaningful." I suggest adding a 
   cross-reference to Webarch section 2.3.1 "URI Aliases" [3] to
   help qualify that statement.

4) Very minor: the word "either" is used in section 3, para 1, but
   refers to 4 options (rather than the expected 2).

[1] http://www.w3.org/2001/tag/issues.html?type=1#siteData-36
[2] http://www.w3.org/2001/tag/doc/alternatives-discovery.html#id2261787
[3] http://www.w3.org/TR/webarch/#uri-aliases
-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447