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 marcin.hanc...@access-company.com: 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 content 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
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 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 marcin.hanc...@access-company.com: 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 content 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. widget xmlns=http://www.w3.org/ns/widgets; content src = start.php type = text/html;charset=Windows-1252 encoding = ISO-8859-1 / /widget In the following example the user agent would set the start file encoding to Windows-1252, if the user agent supports that encoding. widget xmlns=http://www.w3.org/ns/widgets; content src = start.php type = text/html;charset=Windows-1252/ /widget ] 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
[Widgets] LCWD#3 comments (2)
5.3 (grammar: I hope these are final corrections :( ) [*folder-name] Should be *folder-name Since the current form makes it optional twice Zip-rel-path file-name/ could be file-name / (note the space before '/') safe-char I suggest putting the '/' sign at the end of each line instead of at the beginning 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 content element. 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. Path attribute a valid path represent a hierarchical Should be a valid path represents a hierarchical Version attribute e.g. '1.0' is not greater than '2.0' Could be e.g. '1.0' is not less than '2.0' 9.1.10 a) There is no step 11, ol was changed to ul after step 4. b) SNIFF spec basically specifies the algorithms for the resources retrieved from the network. The statement relevant to PC seems to be: For resources fetched from the file system, user agents should use platform-specific conventions, e.g. operating system file extension/ type mappings. Therefore it is unclear what processing filehttp://dev.w3.org/2006/waf/widgets/#file through the [SNIFF]http://dev.w3.org/2006/waf/widgets/#sniff specification. means (i.e. SNIFF is big, but we need just one sentence?). Are we restricted e.g. to section 5 (Unknown Type)? c) The version of the SNIFF spec that is referred by PC is 00 (by date) and it has already expired as ID. 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 Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.