W3C

List of comments on “Widgets 1.0: Packaging and Configuration” (dated 28 May 2009)

Quick access to

There are 49 comments (sorted by their types, and the section they are about).

1-20 21-40 41-49

general comment comments

Comment LC-2213: Marcin versioning
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: in
Not assigned
Resolution status:

(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2240: Rule for Getting Text Content
Commenter: Anne van Kesteren <annevk@opera.com> (archived message)
Context: 8 Configuration Document 8.1 Namespace 8.2 Proprietary Exte...
assigned to Marcos Caceres
Resolution status:

I don't really like the optional ITS behavior. Also, what is the effect of having it there?

If this is a feature needed by authors it also seems better for them if they have it without all the additional namespaces.

textContent is an attribute, not a property. In bindings it might turn into a property, but that is not relevant I think.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2205: Marcin Interop of self regulated values
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: 8.3 Attribute Types
Not assigned
Resolution status:

8.2
For the sake of interoperability, extensions to the configuration document are NOT RECOMMENDED.

8.3
User agents SHOULD impose their own implementation-specific limits on the values of otherwise unconstrained attribute types, e.g. to
prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

So what is actually said about interoperability?
Extension to the configuration document is a similar interoperability issue as the implementation-specific limit is, IMHO.
Rules for limits or simply limits shall be specified to facilitate interoperability.



________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2206
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: 8.12 The feature Element
assigned to Marcos Caceres
Resolution status:

Regarding http://dev.w3.org/2006/waf/widgets/#the-feature-element

I don't understand the purpose and utility of the <feature> element.

> Using a feature element denotes that, at runtime, a widget may
> attempt to access the feature identified by the feature element's
> name attribute.

Why is this useful to denote? What happens if a widget doesn't denote
that it'll attempt to use a feature but does so anyway?

> Using a feature element denotes that, at runtime, a widget may
> attempt to access the feature identified by the feature element's
> name attribute.


Why aren't all the implemented features simply available like in a Web
browser engine?

> A user agent can expose a feature through, for example, an API, in
> which case a user agents that supports the [Widgets-APIs]
> specification can allow authors to check if a feature loaded via the
> hasFeature() method.

Wouldn't this have all the same problems that DOM hasFeature() has had
previously and the problems that have been pointed out as reasons not
to have feature detection at-rules in CSS? Namely, that
implementations have the incentive to claim that they have a feature
as soon as they have a partial buggy implementation.

> A boolean attribute that indicates whether or not this feature must
> be available to the widget at runtime. In other words, the required
> attribute denotes that a feature is absolutely needed by the widget
> to function correctly, and without the availability of this feature
> the widget serves no useful purpose or won't execute properly.

What's a widget engine expected to do when an unrecognized feature is
declared as required?

> <feature name="http://example.org/api.geolocation" required="false"/>


Suppose a WG creates a feature for the Web, the feature is not part of
the Widgets 1.0 Family of specs and the WG doesn't assign a feature
string for the feature because the WG doesn't consider widgets. Next,
suppose browser engines implement the feature making it
unconditionally available to Web content.

Now, if such a browser engine is also a widget engine, does it make
the feature's availability on the widget side conditional to importing
it with <feature>? If it does, what's the point of not making the
feature available unconditionally? If it doesn't, what's the point of
<feature>?

If there are two such engines, how do they converge on the same
feature name string of the specifiers of the feature itself just meant
it to be available to Web content unconditionally and didn't bother to
mint a widget feature string?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2245: One element is allowed per language
Commenter: Anne van Kesteren <annevk@opera.com> (archived message)
Context: Step 7 - Process the Configuration Document
assigned to Marcos Caceres
Resolution status:

The example does not match the prose description. The prose does not say anything about using an element without an xml:lang attribute. (Strangely enough.)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2223: Process blocker
Commenter: Anne van Kesteren <annevk@opera.com> (archived message)
Context: Rule for finding a file within a widget package
assigned to Marcos Caceres
Resolution status:

On Wed, 10 Jun 2009 17:20:25 +0200, Marcos Caceres <marcosc@opera.com> wrote:
> On Wed, Jun 10, 2009 at 4:57 PM, Anne van Kesteren<annevk@opera.com>
> wrote:
>> "TO BE WRITTEN, PLEASE IGNORE" if normative material is yet to be
>> written you cannot enter Last Call. Per
>> http://www.w3.org/2005/10/Process-20051014/tr.html#return-to-wg it
>> seems you have to publish this as Working Draft again.
>
> You are reviewing the (bleeding-edge) editor's draft, Anne. Not the
> published one. That is obviously not in the published draft [1], it's
> just something I put in there yesterday during the F2F and have not
> had a chance to finish yet... I will finish that bit tomorrow.
> Obviously, that won't be in the final draft.
>
> [1] http://www.w3.org/TR/widgets/

Oh ok. All the more reason the cited process document applies though, methinks.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2222: Wouldn't it be nice...
Commenter: Anne van Kesteren <annevk@opera.com> (archived message)
Context: Verify the Zip archive
assigned to Marcos Caceres
Resolution status:

It would actually be nice if a Zip archive with a single folder was allowed so you could just package a folder as Zip and ship it. Is that deliberately excluded?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

typo comments

Comment LC-2204: Marcin 5
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: 5.3 Zip Relative Paths
Not assigned
Resolution status:

5.3
encoding indicator
should be
Language encoding flag (EFS)
to match http://www.pkware.com/documents/casestudies/APPNOTE.TXT

________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2215: Feature typo.
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: 8.12 The feature Element
Not assigned
Resolution status:

Hi Marcos,

The following typo has been found by BONDI contributors.

The example in http://dev.w3.org/2006/waf/widgets/#the-feature-element now specified as:

<widget xmlns="http://www.w3.org/ns/widgets">

<feature name="http://example.org/api.geolocation"
required="false"/>
</widget>

should read:

<widget xmlns="http://www.w3.org/ns/widgets">

<feature name="http://example.org/api/geolocation"
required="false"/>
</widget>

to follow the convention contributed by BONDI.
The api.geolocation shall be changed to api/geolocation.

I/we hope it can be fixed soon.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com


________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2200: Feature editorial
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: 8.12 The feature Element
assigned to Marcos Caceres
Resolution status:

Hi Marcos,

The following typo has been found by BONDI contributors.

The example in http://dev.w3.org/2006/waf/widgets/#the-feature-element now specified as:

<widget xmlns="http://www.w3.org/ns/widgets">

<feature name="http://example.org/api.geolocation"
required="false"/>
</widget>

should read:

<widget xmlns="http://www.w3.org/ns/widgets">

<feature name="http://example.org/api/geolocation"
required="false"/>
</widget>

to follow the convention contributed by BONDI.
The api.geolocation shall be changed to api/geolocation.

I/we hope it can be fixed soon.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com


________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2226: Marcin 9
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: Step 7 - Process the Configuration Document
assigned to Marcos Caceres
Resolution status:

Hi Marcos,

I have found other typos:
Step 7, <icon>;
"Let file the result of applying"
Should be
"Let file be the result of applying"

6.6.2
"A default icon is an reserved icon ..."
Should be
"A default icon is a reserved icon ..."

"A default icon must be located either at the root of the widget package or at the root of a locale folder."
is repeated twice.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com


________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2235: Josh-1097
Commenter: Josh Soref <josh.soref@nokia.com> (archived message)
Context: Misc typos and editorial changes in (Misc sections)
assigned to Marcos Caceres
Resolution status:

Date: Tue, Jun 16, 2009 at 11:42 AM

8:42 AM me: A conformance checker (CC) is a user agent that verifies
if a widget package and a configuration document conform to this
specification.
  if => whether
________________________________
56 minutes
9:38 AM me: <li>when the <a class="no-toc no-num"
href="#rule-for-verifying-a-file-entry0">rule for Verifying a File
Entry</a><span></span> is applied to the file, it returns
  the empty span is probably a bug
9:39 AM 6.3 Reserved File and Folder Names
  Reserved File Names
  you need to change 'xml' to '.xml' and similar
9:40 AM The [Widgets-DigSig] specification also defines the naming
conventions for a distributor signature and the naming convention for
an author signature.
  i think you want 'for distributor signatures' and 'for author
signatures' (plural for both)
________________________________
19 minutes
10:00 AM me: via a an access control policy.
  drop "a"
10:02 AM Marcos: end user should not be defined, me thinks
 me: fine by me
10:03 AM Marcos: I'm too nice to people like Benoit who want things
like that defined but are not actually useful in the spec
10:06 AM Re: "said -> mentioned?" I like "said" as it implies that a
thing will be mentioned when the term is used. However, if you think
it causes confusion, I will change it or clarify it
10:07 AM used mentioned
10:09 AM me: given?
  "a said" just sounds really odd
  a google search for "a said" fails
  the hits are all for people :)
10:14 AM Marcos: all fixed now :)
10:15 AM fixed for both supported and unsupported. No other instances found.
10:19 AM me: so, i'm not a fan of "out of scope of" (very few google
hits), i prefer "beyond the scope of" (millions of hits)
10:20 AM Marcos: nice
10:21 AM me: The start file of a widget package is a file that is used
by the user agent when the widget is instantiated.
  kinda useless statement
  you use the configuration file when the widget is instantiated too
10:22 AM you kinda want to somehow explain that it's more than a file
that's used. although w/o limiting things to DOM style :)
10:25 AM does Default Start File actually specify the order in which
one is found
  and if so, does it define a name for the thing that's found?
  When a start file is not explicitly declared via the content
element, then start file will be one of the default start files.
10:26 AM it'd be better if you could just reference the
algorithmically determined start file instead of hand waving at a list
________________________________
31 minutes
10:58 AM me: might not be supported on all user agents.
  on => by
  then Make sure that the widget is labeled with an
  why is Make capitalized?
 Marcos: no reason
11:00 AM me: you use case-sensitively 5 times and as case-sensitive 4 times
  i don't like the latter :)
  "as case-sensitive" => "case-sensitively"
11:01 AM Marcos: sorry, distracted with our big product launch
  http://unite.opera.com/
11:02 AM me: yeah, sorry, i don't care ;-), but i don't need realtime
responses :)
________________________________
17 minutes
11:19 AM me: <feature name="http://example.com/camera">

<param name="autofocus" value="true"/>
  random blank line between those two?
  width = "200"
viewmodes = "application fullscreen">
11:20 AM most things line up in this tag's attribute list, except viewmodes
  <preference name ="apikey"
11:21 AM this tag doesn't get spaces after =,... if you're trying to
demo lots of different styles, ok, but please note that somewhere,
otherwise, ick :)
  Be sure to declare the widget namespace as part of the widget
element. If the namespace is absent, then Zip archive will be treated
as an invalid Zip archive.
11:22 AM it's odd to mark a zip file as invalid because of an error in
the widget
  shouldn't the widget be invalid instead
  ?
11:24 AM Some general rule
  rules (plural)
11:28 AM Keyword list attribute
  oh fun, "this,is,forbidden"
11:30 AM do we need to say that ".", "..", "...", .... are interesting?
11:33 AM either by default as part of the [XML] specification (as is
the case with xml:lang) or if the user agent implements the optional
[ITS] specification.
  i don't think "either .. if" is a well accepted concept :)
11:34 AM drop "either" (it only fits "either .. or")
________________________________
5 minutes
11:40 AM me: Avoid subtags from the IANA Language Subtag Registry
marked as deprecated, grandfathered, or redundant. The intended
purpose of the xml:lang attribute is to declare the primary language
of an element, its attributes, and its descendent nodes.
  shouldn't CC's complain about them too?
11:42 AM A valid URI that denotes an identifier for the widget. It is
optional for authors to use this attribute.
  why mention 'authors'?
  does anyone else write this file? :)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2236: Josh-1101
Commenter: Josh Soref <josh.soref@nokia.com> (archived message)
Context: Misc typos and editorial changes in (Misc sections)
assigned to Marcos Caceres
Resolution status:

Date: Thu, Jun 18, 2009 at 4:52 PM

4:15 PM me: (e.g., floating and application mode)

either floating mode and application mode
or the floating and application modes
  The following example shows the usage of the name element.

<widget xmlns="http://www.w3.org/ns/widgets">
<name short="Weather">
The Ultimate Weather Widget


probably indent "The" one more space :)
________________________________
19 minutes
4:35 PM me: file identification table
has 3 columns, one is entirely empty
4:36 PM Step 1 - Acquire a Potential Zip Archive
Step 1 involves acquiring a potential Zip archive
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2237: Josh-1102
Commenter: Josh Soref <josh.soref@nokia.com> (archived message)
Context: Misc typos and editorial changes in (Misc sections)
Not assigned
Resolution status:

Date: Thu, Jun 18, 2009 at 6:48 PM

6:36 PM me: (e.g., a user agent could use an array, or an object, or a
hash map, etc.).
drop each "or"
6:41 PM For each element in the elements list, if the element is one
of the following:
A preference element:
doesn't mention readonly (this might be ok, or maybe not...)
6:48 PM 1. For each file name in the default start files table (from
top to bottom) that has a media type that is supported by the user
agent:
1. Let potential-start-file be the result of applying the rule for
finding a file within a widget package to file name.
2. If potential-start-file is null or in error, ignore this file name
and move onto the next file name in the default start files table.
3. If potential-start-file is a file, then:
1. Let widget start file be the value of potential-start-file.
2. Let start file content-type be the media type given in the media
type column of the default start files table.
3. Terminate this algorithm and go to Step 9.

I'm worried about the case where a package has two files: index.svg
and index.xhtml. index.svg is 0 bytes and index.xhtml is a well formed
xhtml file. The author developed this package using a user agent which
doesn't support image/svg+xml and things worked well. A user
unfortunately gets the widget and uses it with a user agent which does
support image/svg+xml. I'm fairly certain what happens is that this
process sends the user agent to step 9 with index.svg and the user
ends up unhappy.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2214: Jere, General Editorial Comments
Commenter: <Jere.Kapyaho@nokia.com> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

Marcos, all,

some more review comments for Widgets 1.0 Packaging and Configuration LC
(Working Draft 28 May 2009), this time of a more general nature (not so much
L10N-related).


/1/ RFC 2119 keyword usage

In writing specs, the work split between MAY and SHOULD is sometimes
problematic. I tend to use MAY when there is something that is slightly "out
of line" but permissible in some cases, and SHOULD when it is generally a
very good idea or almost mandatory to do something, but it can be skipped
given enough reasons.

This is why I reacted to this statement in section 3.1:
"A user agent MAY support the [Widgets-DigSig] specification ..."
And would have written it as:
"A user agent SHOULD support ..."

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

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

5 Zip Archive
It would be enough to say: "The packaging format for the files of a widget
is the Zip archive format as defined in the [ZIP] file format
specification."

For conformance (last paragraph in section before note) I suggest, for
clarity: "To conform to this specification, a Zip archive MUST contain one
or more file entries and MUST be a valid Zip archive." (c.f "MUST NOT be
invalid")

5.2 Version of Zip
For Zip version 2.0 features, the MAYs should not be marked up as keywords.

8.5 The widget element, definition of width attribute: "Which view modes
SHOULD honor the value of this attribute is defined in the the
[Widgets-Views] specification". This is invalid keyword usage, suggest to
replace with: "The view modes that honor the value of this attribute are
defined in the [Widgets-Views] specification."


/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. As soon as you move
out of US-ASCII range, the bytes CP437 and UTF-8 will be different even for
the limited number of non-US-ASCII chacters that CP437 can represent.

Marcin has already commented on the ABNF of utf8-chars, I'll participate in
that discussion if necessary.

5.4 Reserved Characters: suggest to reverse the order of the glyph and
character columns.

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


/3/ JPEG icons

This may have been beaten to death before, but I wondered why a JPEG file is
not allowed as the default icon.


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

In 8.2 Proprietary Extensions, first para, last sentence: "For the sake of
interoperability, extensions to the configuration document are NOT
RECOMMENDED". Two problems: 1) "NOT RECOMMENDED" is not valid keyword usage;
2) it is OK to extend the configuration document because there is a
well-defined mechanism that uses namespaces. Suggestion: remove this
statement.

Version attribute: in the ABNF, doesn't "1*2DIGIT" mean that a version
number like 123 would be invalid? Especially build numbers are often three
or four digits long. Of course, this is only a guideline, but still...

Numeric attribute: apparently all numeric attributes are non-negative. Isn't
there any use case for negative numbers, ever? Also, non-Western numerals
are not acceptable by this definition, but that might not be a showstopper
in this case.

Keyword attribute: Is the set of allowable characters inherited straight
from the XML spec? 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?

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


/5/ Rule for Parsing a Non-negative Integer

Couldn't we just refer to some well-established definition, if there is one
handy? Seems like this must have been done many times before. And what about
those negative numbers, then? Not needed? :-)

Hope this helps,
Jere @ Nokia
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2249
Commenter: <ishida@w3.org> (archived message)
Context: Document as a whole
assigned to Marcos Caceres
Resolution status:

Comment from the i18n review of:
http://www.w3.org/TR/2009/WD-widgets-20090528/

Comment 2
At http://www.w3.org/International/reviews/0907-widgets-pc/
Editorial/substantive: E
Tracked by: AP

Location in reviewed document:
Section 8.3 [http://www.w3.org/TR/2009/WD-widgets-20090528/#attribute-types]

Comment:
Section 8.3 (Attribute Types) contains a subsection called "URI Attribute" which is relevant to our comment above. It says:

--

An attribute defined as containing a valid URI. A valid URI is one that matches the URI token of the [URI] specification or the IRI token of the [RFC3987] specification. The value of this kind of attribute is retrieved using the rule for getting a single attribute value. --

This is problematical, since all URIs are IRIs, but not the converse. We think this should favor IRI and note the relationship to URI.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2216: P&C LC comments on I18N/L10N
Commenter: <Jere.Kapyaho@nokia.com> (archived message)
Context: Document as a whole
assigned to Marcos Caceres
Resolution status:

Marcos, all,

here's a bunch of comments related to the I18N/L10N related parts of the
Widgets 1.0: Packaging and Configuration spec (Last Call i.e. Working Draft
28 May 2009).

/1/ Order of material

>From an editorial standpoint, I think that the "7.2 Examples" subsection
should really be the last one in this section.

Information about element-based localization, which now is 8.15, should
appear in section 7, because the concepts are used in Section 8 before they
are even defined. It would be good to have all related info in the same
section.

My suggestion for the organization of the material is:

7 Internationalization and localization
7.1 Localization guidelines
7.2 Folder-based localization (used to be 7.3)
7.3 Element-based localization (used to be 8.15)
7.4 Localization examples (used to be "7.2 Examples", note new name)

This would make the material flow better and have all the concepts defined
before they are used.

Also, the whole of Section 7 should actually appear right before the
processing steps (i.e., after the current Section 8).


/2/ Content of examples

The localization examples are non-normative, but many developers are going
to study them closely, so it pays to fine-tune them a little (and fix a few
bugs).

In the simple example, the second file "/sp/index.html" should be labeled
"/locales/es/index.html". Similarly, in the complex example, "/locales/sp/"
should be "/locales/es".

The complex example refers to several files which really have the same
purpose. I think they should also have the same name, otherwise they cannot
be found by the same reference. That is, "/locales/es/gatos.html" should be
called "/locales/es/cats.html". Or is it intentional?

In "Fallback Behaviour Example", first paragraph, last sentence should read:
"The purpose of this 'fallback' model is to reduce the number of files that
need to be created in order to achieve localization of a widget package."
(remove 'n' from 'then', add 'in order')


/3/ Folder-based localization

Suggested addition to the authoring guideline: "A Conformance Checker (CC)
SHOULD issue a warning if there are empty locale folders in the widget
package."

This statement in the authoring guideline is puzzling: '[That is,] authors
cannot simply put shared files into a language level folder, but need to put
all files needed into the language level folder for the widget to work (for
example, having "a.gif" in both "/locales/zh-Hans/" folder and
"locales/zh").' Isn't this the opposite of what is supposed to happen in the
fallback model? If the same "a.gif" is good for both zh-Hans and zh, it
should be possible for the author to include it just once in "/locales/zh".
If the user's language list includes 'zh-Hans', it will also include 'zh',
as per Step 5. So "a.gif" will be found eventually.

Replace '"shared1.gif, shared2.gif"' with '"shared1.gif" and "shared2.gif"'.

Priority is probably a bad term to use with regard to localized folders.


/4/ The xml:lang attribute

Does the XML specification state that the values of xml:lang attributes must
be unique across instances of the same element? If yes, it is probably
redundant to repeat that in the context of all the elements in the
configuration document. If not, the statement about uniqueness could still
be factored out, for example to section 8.4, to avoid repetition.


/5/ Processing steps

Step 3: the concept of "localized config doc" appears in the Configuration
Defaults table, but that doesn't seem to exist anymore. (See also Step 6.)

Step 5: replace "unprocessed locales lists" with "unprocessed locales list"
throughout.

Consider replacing "user agent's locales" with "user agent locales"
throughout the spec.

In the first example of Step 5, why would en and en-au be swapped around
when decomposed? Would 'canonicalization' be a more suitable term here than
'decomposition'?


/6/ Runtime resolution of localized resources

What specification should describe how a reference to a resource (which
could be in a localized folder) is resolved at runtime, based on the user's
language range? That is not quite in the domain of the packaging
specification, given that it is runtime behavior. This functionality is
sketched in the fallback behavior example, but it is non-normative.


Thanks for considering these comments.

Best regards,
Jere @ Nokia
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2251
Commenter: (wrong string) Å„ski <1981km@gmail.com> (archived message)
Context: Document as a whole
assigned to Marcos Caceres
Resolution status:

Dear Marcos and WG,

Here follows my set of remarks on Widgets 1.0: Packaging and Configuration which I hope you'll find valuable during LC review. It's based on the 17th June Editor's Draft.

> http://www.w3.org/TR/2009/WD-widgets-??/
Error 404. "TBD" in place of IRI would be better.

> Latest Editor's draft:
In other places the word "draft" is also capitalized.

> Marcos Cáceres
This remark is positive: nice to see the name spelled correctly. (Some WGs and the server at lists.w3.org have problems with mine.)

> a class of software application
Was plural intended?

> while processing the packaging format, configuration document, and other relevant files
I can accept that the non-webby notion of files is used in the Zip spec and as such adequate for what's contained in Zip archives. But, as we have already discussed, for other uses please write "resources".

> Rich Web Clients Activity
This is not an issue of the document itself, but worth mentioning, especially since it's your Activity. The W3C site uses inconsistent naming: sometimes it's "Clients" and in other places "Client". Be sure to pick the correct one.

> 1 Introduction
Is the text before 1.1 normative?

> While a conforming user agent may support other legacy/proprietary widget types in order to conform to this specification, a user agent must treat widget packages as according to this specification.
I find this sentence unclear.

> The magic numbers for a Zip archive is the byte sequence
Aren't those officially called octets?

> other compression formats will cause the widget package to be treated as an invalid Zip archive.
In the context of definitions present in the document this would effectively render the OPTIONAL (so says 3.1) support for other compression formats useless. As an authoring guideline, this text isn't normative, so if included in the final spec, should be considered false. Of course false statements are to be avoided.

> If a CC encounters a compression method that is not one of the valid compression methods,then the CC must inform the author that the Zip archive is an invalid Zip archive.
This, on the other hand, is normative. So the problem is serious. I suggest lowering this to a warning by CC that user agents will be allowed to treat the Zip archive as invalid.

> For the sake of comparison and matching, it is recommended that a user agent internally treats all Zip-relative paths as [UTF-8].
What does "internally treats" mean? Is there a risk of violating Charmod, or are Zip archive internals believed to be out of its scope?

> cp437-chars
This nonterminal seems undefined.

> If the widget package does not contain a start file, or the start file is not one that is supported by a particular user agent, then the CC must inform the author.
How can a CC have knowledge of all user agents? Or do you mean a CC is a user agent (indeed, in general terminology, but this term has been narrowed for this spec in 2)?

> then Make sure that the widget is labeled
Typo.

> Failure to correctly label a widget package will result in it being treated as an invalid Zip archive.
Only if it's first considered to be a potential Zip archive. A generic user agent may process other resources (e.g. image/svg+xml) and only defer to its subcomponent that implements widget specs on encountering application/widget.

> If it is anticipated that the widget will be distributed by non-HTTP means, then include the widget file extension.
Replace "non-HTTP means" by "means lacking MIME support".

> Author Guidelines:
In other places it's
"Authoring guideline:".

> Example of recommended version tags:
They don't belong to the language generated by {rec-version-tag}.

> A URI attribute that represents a link that is associated with the author (e.g. the homepage of the author). It is optional for authors to use this attribute.
This really should be specified as the URI of the author himself. Nowadays still many authors will probably just point to their homepages, but semantically mean themselves, which they'll be able to make explicit at the time they decide they want to, using the techniques described in http://www.w3.org/TR/cooluris/.

> If the file pointed to by the src attribute is of a vector graphic format, then this value must be used.
Why? Vector formats may include preferred sizes specified. Even if not, some environments require specific sizes and it should be assumed that whatever else is specified, will be scaled. In case of vector graphics without intrinsic dimensions I believe it's the environment's responsibility to apply a reasonable default.

> The its:dir attribute and the its:span element may each be used as a child
What data model are you using to call attributes children?

> such as "en-us", "en-gb", and so on
Canonical spelling is "en-US", "en-GB", and so on. Do you intend to require deviating from it?

> However, widget packages localized at any folder level (e.g. "locales/zh/") needs to be fully functional as a localized widget. That is, authors cannot simply put shared files into a language level folder, but need to put all files needed into the language level folder for the widget to work (for example, having "a.gif" in both the "/locales/zh-Hans/" folder and "/locales/zh/").
The "Fallback Behavior Example" in 8.4 suggests otherwise. Could you clarify this issue in the spec, please?

> The steps for processing a widget package involves nine steps that a user agent SHOULD follow
Why not just MAY, given the next paragraph?
It also seems that RFC 2119 keywords are sometimes all-capitalized by style and sometimes in the markup (probably by mistake).

> The rule for determining if a potential Zip archive is a Zip archive are as follows:
Here and in other places probably plural was intended.

> Each item in the unprocessed locales must be a string shorter than eight characters, in lowercase form
I find both of these requirements objectionable. "x-klingon" is 9 characters, country subtags are canonically upper-case and script subtags mixed-case.

> remove all duplicate ranges except the left most one.
s/left most/first (There's international consensus that lists are undirectional data structures.)

> or fileis not present
Typo.

> two or more bits of information
Bit is a unit, so I suggest calling those pieces.

> The term text node refers to any Text node, including CDATASection node
This term is unused.

> This is in error and the user agent must ignore it.
Although in principle naming things arbitrarily doesn't change meaning, it's somewhat difficult to accept that comments are proclaimed to be "in error".

> Once all the elements in the elements list have been processed, go to Step 8.
Overzealous implementation would then perform Step 8 twice, since it's been already instructed before to perform all 9 steps in sequence.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2228: Jeff-Decker
Commenter: Jeff Decker <w3c-updates@celestialwake.com> (archived message)
Context: in (Section )
assigned to Marcos Caceres
Resolution status:

From: Marcos Caceres <marcosc@opera.com>
Date: Wed, 1 Jul 2009 17:11:23 +0200
Message-ID: <b21a10670907010811t381782d4s72fa767bc454b624@mail.gmail.com>
To: Jeff Decker <w3c-updates@celestialwake.com>
Cc: public-webapps@w3.org

On Wed, Jun 17, 2009 at 5:12 PM, Jeff
Decker<w3c-updates@celestialwake.com> wrote:
> Hi Everyone,
>
> I was going over the P&C spec and had a couple questions:
>
> 1. Under section 7.12 "The feature Element" it does not note how a widget
> user agent should handle an unknown feature name. Is this intended?

Yes, this is intentional. Processing is actually defined in Step 7:

"x. If feature-name is not supported by the user agent, and
required-feature is true, then treat this widget as an invalid widget
package.

x. If feature-name is not supported by the user agent, and
required-feature is false, then this element, its attributes, and its
children are in error and must be ignored. Stop processing this
element and proceed to the next element in the elements list.
"

I've added a note at the start of the "Configuration Document" section
referring the reader to Step 7 for details about processing of
elements. Hopefully that will alert the reader to where processing of
elements is described. The note simply reads:

"Please see Step 7 for details of how the elements of the
configuration document are processed by a user agent."

Is that clear enough?

> 2. Under section 6.5 "Start Files" it says "It is optional for user agents
> to support the media types listed in the default start files table." Does
> this mean a user agent can support any combination of Default Start Files
> from the table or are the files grouped under the media types? So If I were
> to support text/html, then I would need to search for both .htm and .html
> files?

That is correct. Is that not clear enough? If no, can you suggest some
text that would make that more clear?

--
Marcos Caceres
http://datadriven.com.au
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2234: Josh-1096
Commenter: Josh Soref <josh.soref@nokia.com> (archived message)
Context: Typos in (Misc sections)
assigned to Marcos Caceres
Resolution status:

http://dev.w3.org/2006/waf/widgets/

Date: Tue, Jun 16, 2009 at 2:52 AM

2:29 AM me: hey
  suppose that times square becomes widget capable
2:30 AM and starts running widgets, like a Clock.wdgt
  who's the "end user"? :){
________________________________
9 minutes
2:40 AM me: Bluetooth is spelled as such, no capital T
  (i.e., users can share widgets over non-HTTP distribution channels,
such as BlueTooth, a USB thumb drive, etc.).
  the idea of using both 'i.e.' and 'etc.' in the same parenthetical
scares me. although it might be correct in this instance
2:41 AM Supported means that a user agent implements a said specification,
  said -> mentioned ?
  "a said" sounds really odd
2:42 AM maybe "listed", "indicated", ... dunno
  Initialization means a run through the steps for processing a widget
package post installation of a widget.
  post => after ?
2:43 AM As well as sections marked as non-normative, authoring
guidelines, diagrams, examples, and notes in this specification are
non-normative.
  is hard to parse.
  <As well as sections marked as non-normative>, <authoring
guidelines, diagrams, examples, and notes> in this specification are
non-normative.
2:44 AM In addition to (non-normative marked|marked non-normative)
sections, all authoring guidelines, ... and notes in this
specification are ... non-normative.
2:46 AM There are four classes of products that can claim conformance
to this specification:
2:47 AM that => which ?
  (very uncertain about that)
2:49 AM Other legacy/proprietary widget types can be supported by a
user agent, but a user agent must conform to this specification when
dealing with a widget package.
  should this say:
2:52 AM While a conforming user agent may support other
legacy/proprietary widget types in order to conform to this
specification it must treat widget packages as according to this
specification.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-49

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.47 2015-01-05 13:17:17 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org