- From: <Jere.Kapyaho@nokia.com>
- Date: Thu, 4 Jun 2009 15:26:51 +0200
- To: <marcosc@opera.com>
- CC: <public-webapps@w3.org>
On 3.6.2009 18.29, "ext Marcos Caceres" <marcosc@opera.com> wrote: On Wed, Jun 3, 2009 at 12:50 PM, <Jere.Kapyaho@nokia.com> wrote: >> "A user agent MAY support the [Widgets-DigSig] specification ..." >> And would have written it as: >> "A user agent SHOULD support ..." > > The point of it being a MAY is that all the user agents are > independent. The architecture of each spec is designed to work > independently of each other where possible. Understood. Just seemed like a slightly odd use of MAY to me. Another way is to use OPTIONAL, but this is not a big issue. >> The same goes for section 3.2. I would say: "a user agent SHOULD support the >> its:span element and the its:dir attribute, and MAY support other ITS >> elements and attributes". Also, the right name for ITS is >> "Internationalization Tag Set" ("ation" vs. "ed"). > > Woops, fixed :) This is now a MAY. WD 3 June 2009: name of section 3.2 has "-ed". :-) Do you agree with the text I suggested above? >> 4 Conformance Checker >> Last sentence in the section: "CCs are NOT REQUIRED to display all messages >> at once". Here, "NOT REQUIRED" is not valid RFC 2119 keyword usage. Suggest >> to remove this sentence altogether, and change the preceding sentence to >> say: "The wording and presentation of the advisory messages are >> implementation-dependent." > > I changed it to: "It is OPTIONAL for a CC to display all messages at once." Alert: Unnecessary use of requirement keyword detected. :-) But I'll let it pass. >> /2/ UTF-8 encoding >> >> So, we still can't mandate the use of UTF-8 as the path encoding? Of course, >> RECOMMENDED is fairly strong, but I would prefer MUST. > > We can, but it would be a waste of time. I don't know any zip > implementation that supports this properly. Widget installer != Zip implementation. I can't provide a counterexample of a Zip *library* that would do it right, so I guess I have to give up on that one... >> 8.11 The content element, definition of charset attribute: >> - Despite widespread use, the name "charset" is not good. A more accurate >> name would be "encoding". >> - Suggest to replace "(a user agent are REQUIRED to support [UTF-8])" with >> "User agents MUST support [UTF-8]." > > changed globally. Great! Though the description of the 'encoding' attribute should also use "character encoding", not "character set". >> /4/ Configuration document >> >> It is not currently an error to have a file called 'config.xml' anywhere >> inside the widget's folder structure. The only one that matters is the one >> in the root folder. Maybe the CC should warn about the presence of multiple >> config.xml documents? > > I don't think this is relevant, as a config file in a folder has no > special meaning. Also, if in the future we migrate to the using > multiple config files for localization, then this might not be > desirable. Is that ok? That is OK. >> Is it self-evident that keywords can't contain spaces >> because it is the keyword list separator? Couldn't comma also be used as a >> separator? > > That's ok, I think. The keyword is just a concept, and the whole value > of attribute is used so spaces, commas or whatever are ok. So > att="this is a keyword with spaces, and comas" would be fine and > treated as an opaque string. Testing my understanding: if some attribute is marked as keyword and not a keyword list, then it's just an opaque string. Only if it is marked as a keyword list the spaces would be significant. If the value you gave as an example above would be parsed as a keyword list, then the result would be the list ["this", "is", "a", "keyword", "with", "spaces,", "and", "comas"]. (Note the comma in "spaces,".) Correct? >> Boolean attribute: it is stated that only "true" and "false" are valid >> values, but that if the value is something else, the default is false. That >> seems like a contradiction. Are values other than literal "true" and "false" >> supposed to be actual errors, or are they silently coerced into false? (If I >> accidentally type required="rue" it would come out as "false"...) > > That is correct. The same would hold for required="TRUE", which would > be "false". Not sure if we should change this or not, or keep it > strict. If by strict you mean that other values besides the literal strings "true" and "false" would be flagged as errors, I would support that. All other responses not further commented here are OK with me. --Jere
Received on Thursday, 4 June 2009 13:27:00 UTC