W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] P&C LC, general comments

From: <Jere.Kapyaho@nokia.com>
Date: Thu, 4 Jun 2009 15:26:51 +0200
To: <marcosc@opera.com>
CC: <public-webapps@w3.org>
Message-ID: <C64DA64B.69CF%jere.kapyaho@nokia.com>
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
>> /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

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

Received on Thursday, 4 June 2009 13:27:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC