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

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

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 16 Jun 2009 15:49:46 +0200
Message-ID: <b21a10670906160649n4c6d1007q2c73f354f67f1e3f@mail.gmail.com>
To: Jere.Kapyaho@nokia.com
Cc: public-webapps@w3.org
On Thu, Jun 4, 2009 at 3:26 PM, <Jere.Kapyaho@nokia.com> wrote:
> 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?

Ok, I checked globally. No more instances of "Internationalized Tag
Set". Promise :)

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

Yes, I'm annoyed at this one too. But I have seriously given up trying
to fight this.

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

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

Yes, that is what I mean. Great.

> All other responses not further commented here are OK with me.

Great! For the sake of the disposition of comments,  can you please
just confirm that all issues in this thread have been addressed.

Kind regards,

Marcos Caceres
Received on Tuesday, 16 June 2009 13:50:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:35 UTC