W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [widgets] Packaging & Configuration 1.0 pre-CfC comments

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Wed, 10 Dec 2008 16:40:09 +0000
Message-ID: <b21a10670812100840l18f0b2a5m8ba57d5f29163c4c@mail.gmail.com>
To: "Jere Kapyaho" <jere.kapyaho@nokia.com>
Cc: public-webapps <public-webapps@w3.org>

Hi Jere,
On Wed, Dec 10, 2008 at 12:47 PM, Jere Kapyaho <jere.kapyaho@nokia.com> wrote:
> Hi Marcos,
>
> finally I got the chance to read the Widgets 1.0 Packaging & Configuration
> spec. Great work there; please accept some comments based on the Editor's
> Draft 7 December 2008 version, up at [1].
>
> 5.3 Zip Relative Paths
> The ABNF needs some polishing:
> - Rule names like cp437 vs. cp437-chars, utf8-range vs. utf8-chars,
> ascii-range vs. ascii-chars.

Fixed.

> - ABNF rules are case-insensitive as per RFC 5234 [2]; does this affect the
> Language-Tag rule in any way?

No, they are also case insensitive.

> - delimiter should be %x2F or just "/" for readability

used "/".

> - In cp437-chars, should say %x80-FF (and no semicolon)

fixed.

> - s/is define in/is defined in/

fixed.

> 5.4 Reserved characters
> - Minor issue with the table of reserved characters: the "Unicode code
> points"

Fixed.

>column would be better labeled "Unicode character" and be made the
> first column.

Fixed.

>The CP437 column is redundant, IMHO.

Right. dropped it.

> The column "Character
> representation" could be just "Representation" or "Representative glyph".
>

Used  Representative glyph.

> - Are filenames of ZIP entries case-sensitive or not? The ZIP spec does not
> seem to say (or I missed it), but the P&C spec has several recommendations
> about case.
>

I think they are case insensitive. So, if you have two file entries
with the same file name (say "a" and "A") inside a zip file, upon
decompression, one will override each other. This is also a problem on
operating systems that are case insensitive.

> 6.4 Content localization
> - Note that since localized folders now must reside in the root of the
> widget package, they "pollute" the root namespace, and it is possible to
> (more or less accidentally) have a normal folder whose name is a valid BCP47
> language tag. In essence, all valid BCP47 language tags would have to be
> treated as "reserved". Should the localized folders instead be placed one
> level down from the root, inside folder 'X', where 'X' is a suitable
> reserved name like 'resources'?

I don't think this is necessary. We should maybe add a conformance
checker behavior to warn authors about this.

> - If there ever is a case of the WUA having to iterate all the localized
> folders, I think it's going to be difficult or impossible to find them all.

Is this a problem with the way the algorithm in the spec is written?
or is this a problem with with BCP47?

> We had this problem in JSR 238 [3], and ended up having a metadata entry
> that lists the supported locales. It can be generated by a widget packaging
> tool. Not ideal, but beats a combinatorial explosion... :) Or maybe you
> envision that the lang-priority-list removes the need to iterate?

If the problem is with strangely formed langauge tags, I wonder if
conformance checkers will help there?

> 6.5 Start file and Default Start Files
> "See Step X for instructions of how to find the default start file." -- here
> X should probably be 9.
>

Fixed.

> 8. Steps for Processing a Widget Resource
> Step 6 - Determine the base folder and widget locale
> - Algorithm step 2.d.i.2 seems to be missing something ("Let base folder
> .").

Ok, it's now "Let base folder be the name of the folder that matched
the current range."

> - Algorithm step 2.d.ii refers to "this step 2.4".
>
fixed. Should have been 2.d

> References
> - ZIP file spec: seems to be revised from time to time, would it be good to
> freeze the reference to a particular version?

Agreed. We will probably freeze on 6.3.1.

> - Might want to fill in the HTTP, URI, ABNF etc. references before formal
> publication. BTW, did you already get someone to volunteer to do it? I'll
> help if not too late.

I haven't had anyone volunteer (though Mohamed Zergaoui sent in some
comments regarding what needed fixing[1]). I would _really_ appreciate
any help you can give me!

> - Make all the URIs also links (like BCP47).
>
Will do.

Kind regards,
Marcos

[1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0436.html
-- 
Marcos Caceres
http://datadriven.com.au
Received on Wednesday, 10 December 2008 16:40:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT