Re: [Widgets] LCWD#3 comments (2)
Marcin Hanclik wrote: Hi Marcos, 3. say that parameter is allowed, but if it includes an encoding parameter, then @encoding beats it (or the other way around). OK " let start file encoding be the value of the last supported parameter components whose purpose is to declare the character encoding of the start file." Should be " let start file encoding be the value of the last supported parameter component whose purpose is to declare the character encoding of the start file." (components -> component) Fixed What we should do here is quickly ask Adam Barth to take a look at what we have specified and make sure it is ok. OK. For the purposes of my LC comments, I am satisfied with your response up to the next line. Great. I have recorded your approval in the DoC!
RE: [Widgets] LCWD#3 comments (2)
Hi Marcos, >>3. say that parameter is allowed, but if it includes an encoding >>parameter, then @encoding beats it (or the other way around). OK " let start file encoding be the value of the last supported parameter components whose purpose is to declare the character encoding of the start file." Should be " let start file encoding be the value of the last supported parameter component whose purpose is to declare the character encoding of the start file." (components -> component) >>heh, good point (I honestly don't know which fools let me be a spec >>editor; I'm s obviously not qualified! just hope no one will >>notice :) ) ;) Keep up! You are doing a great job! I am just reviewing :) >>What we should do here is quickly ask Adam Barth to take a look at >>what we have specified and make sure it is ok. OK. For the purposes of my LC comments, I am satisfied with your response up to the next line. >>> It is unclear why the valid-MIME-type production requires “parameter”. I will send another email with comments on this grammar. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Thursday, November 19, 2009 2:54 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [Widgets] LCWD#3 comments (2) Hi Marcin, All, Marcin has identified an issue with the spec that requires input from people that know the MIME. Please see the changes I have proposed to the spec below. 2009/11/18 Marcin Hanclik : > 5.3 (grammar: I hope these are final corrections L ) > > > > [*folder-name] > > Should be > > *folder-name > > Since the current form makes it optional twice Right. Fixed. > > > Zip-rel-path > > file-name/ > > could be > > file-name / > > (note the space before ‘/’) Noted and fixed :) > > > safe-char > > I suggest putting the ‘/’ sign at the end of each line instead of at the > beginning > Done. > > 7.4 > > Media type attribute > > It is unclear why the valid-MIME-type production requires “parameter”. > > “parameter” could specify the charset and that could conflict with the > @encoding attribute of the element. > This is true and a really good point. It was actually the reason I included the parameter part (so you didn't need the encoding attribute). And also because parameters could appear, in which case I didn't want those strings to be treated as invalid - and hence make the whole widget invalid! However, given that I forgot to specify the behavior for the situation you describe, we should either: 1. kill the parameter bit - using the ABNF you suggest below. 2. say that it is allowed, but left up to the implementation. 3. say that parameter is allowed, but if it includes an encoding parameter, then @encoding beats it (or the other way around). I don't particularly like 1, because I can imagine use cases where one could automatically convert a web page into a widget and retain the Content-Type: header for a resource without needing to strip out the parameters. Having the parameters would automatically make the content type invalid and, hence, ignored by the UA, which I don't think is right. I share your concerns about 2, because it is ambiguous. I guess 3 seems like the right thing to do. I think @encoding should win - but I don't have a technically valid reason why... maybe just because it could serve as an explicit override. Here is a proposed text, to go into Step 7 as part of the content element parsing rule. I've added it to the latest draft. Please take the time to review it. [ [if it's ] A content element: ... 7. If the encoding attribute is used, then let content-encoding be the result of applying the rule for getting a single attribute value to the value of the encoding attribute. If the character encoding represented by the value of content-encoding is supported by the user agent, then let the start file encoding be the value of content-encoding. If content-encoding is an empty string or unsupported by the user agent, then a user agent must ignore the encoding attribute. 8. If the type attribute is used, then let content-type be the result of applying the rule for getting a single attribute value to the value of the type attribute. If the value of content-type is a media type supported by the user agent, then let the start file content-type be the value of content type. If value of content-type is invalid or unsupported by the user agent, then a user agent must treat the widget package as an invalid widget package. 9. If the start file encoding was set in step 7 of this algorithm as a result of
Re: [Widgets] LCWD#3 comments (2)
Hi Marcin, All, Marcin has identified an issue with the spec that requires input from people that know the MIME. Please see the changes I have proposed to the spec below. 2009/11/18 Marcin Hanclik : > 5.3 (grammar: I hope these are final corrections L ) > > > > [*folder-name] > > Should be > > *folder-name > > Since the current form makes it optional twice Right. Fixed. > > > Zip-rel-path > > file-name/ > > could be > > file-name / > > (note the space before ‘/’) Noted and fixed :) > > > safe-char > > I suggest putting the ‘/’ sign at the end of each line instead of at the > beginning > Done. > > 7.4 > > Media type attribute > > It is unclear why the valid-MIME-type production requires “parameter”. > > “parameter” could specify the charset and that could conflict with the > @encoding attribute of the element. > This is true and a really good point. It was actually the reason I included the parameter part (so you didn't need the encoding attribute). And also because parameters could appear, in which case I didn't want those strings to be treated as invalid - and hence make the whole widget invalid! However, given that I forgot to specify the behavior for the situation you describe, we should either: 1. kill the parameter bit - using the ABNF you suggest below. 2. say that it is allowed, but left up to the implementation. 3. say that parameter is allowed, but if it includes an encoding parameter, then @encoding beats it (or the other way around). I don't particularly like 1, because I can imagine use cases where one could automatically convert a web page into a widget and retain the Content-Type: header for a resource without needing to strip out the parameters. Having the parameters would automatically make the content type invalid and, hence, ignored by the UA, which I don't think is right. I share your concerns about 2, because it is ambiguous. I guess 3 seems like the right thing to do. I think @encoding should win - but I don't have a technically valid reason why... maybe just because it could serve as an explicit override. Here is a proposed text, to go into Step 7 as part of the content element parsing rule. I've added it to the latest draft. Please take the time to review it. [ [if it's ] A content element: ... 7. If the encoding attribute is used, then let content-encoding be the result of applying the rule for getting a single attribute value to the value of the encoding attribute. If the character encoding represented by the value of content-encoding is supported by the user agent, then let the start file encoding be the value of content-encoding. If content-encoding is an empty string or unsupported by the user agent, then a user agent must ignore the encoding attribute. 8. If the type attribute is used, then let content-type be the result of applying the rule for getting a single attribute value to the value of the type attribute. If the value of content-type is a media type supported by the user agent, then let the start file content-type be the value of content type. If value of content-type is invalid or unsupported by the user agent, then a user agent must treat the widget package as an invalid widget package. 9. If the start file encoding was set in step 7 of this algorithm as a result of processing a valid and supported value for the content element's encoding attribute, then skip this step in this algorithm. Otherwise, if the value of content-type is a media type supported by the user agent and if content-type contains one or more [MIME] parameter components whose purpose is to declare the character encoding of the start file (e.g., the value "text/html;charset=Windows-1252", where charset is a parameter component whose purpose is to declare the character encoding of the start file), then let start file encoding be the value of the last supported parameter components whose purpose is to declare the character encoding of the start file. In the following example, the user agent would set the start file encoding to ISO-8859-1 and would ignore the charset parameter used in the type attribute. http://www.w3.org/ns/widgets";> In the following example the user agent would set the start file encoding to Windows-1252, if the user agent supports that encoding. http://www.w3.org/ns/widgets";> ] > Also the valid-MIME-type could be replaced with the following from RFC4288 > type-name = reg-name > subtype-name = reg-name > reg-name = 1*127reg-name-chars > reg-name-chars = ALPHA / DIGIT / "!" / > "#" / "$" / "&" / "." / > "+" / "-" / "^" / "_" > > BTW: > > I understand that W3CMediaReg uses RFC2046 (actually RFC2048), but RFC4288 > (also BCP13) obsoletes RFC2048. > > So it gets blurred to me. I don't know which reference would be correct, so lets just run with the classic one. > > > Path attribute > > “a valid path represent a hierarchical” > > Should be > > “a valid path represents a hierarchical” Fi