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

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.

Thanks.
>>> /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".

Fixed.

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

Great.

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

-- 
Marcos Caceres
http://datadriven.com.au

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