Disposition of comments for the Web Applications Working Group

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.

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.

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

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

Location in reviewed document:
Section 9.1, step 4 [http://www.w3.org/TR/2009/WD-widgets-20090528/#step-4--locate-and-process-the-digital-s]

Comment:
In this same step, substep 4 is unnecessary. It does save processing time, but it is not required for proper operation. Performing the specific change suggested also has the negative side-effect of altering the user's preferences ahead of the local configuration. The rightmost occurrence would be a better choice for elimination.

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

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

I think the first paragraph here can be dropped as you cannot test it. Optionally you could rephrase it as a non-normative note.

Why are "Reserved Characters", "control characters", and "space characters" presented in such a different way? It seems that they can be done in a single style in a single place.

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?

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.

This has the same problem with file-extension requiring a leading dot and the table not having any.

The prose also does not make it clear that the entries in the first column may be comma-separated (and can have leading spaces, to be pedantic).

Why not use audio/wav or audio/wave for WAVE files?

An additional column mentioning the format might be nice for readers.

There's no need to recommend something twice so everything after the last semicolon can be dropped.

The usage of "inform" here assumes the user agent in question is a conformance checker. However, it is far more likely that this is a normal user agent that can run widgets. As such, the usage of inform here is inappropriate for that class of products.

Why does this not reuse the general definition of space characters? Same comment applies to "Rule for getting a list of keywords from an attribute" it seems.

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.

This introduces yet another definition of whitespace, good times!

It also talks about elements in a completely different way than the algorithm just before it. This would also do well with a consistent style I think.

The algorithm itself deals with leading and trailing spaces. The additional requirement about them makes matters confusing. Please remove it.

For SVG "none, see comment." does not help as the comment does not clarify what is supposed to happen. I think the correct answer here is that SVG only works if you use the proper extension and it would be worthy to point that out crystal clear.

Also, following the definition of file-extension _none_ of the entries in the table would be matched. I.e. file-extension requires a leading dot.

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

"This means that the user agent must match all elements of a particular type whose xml:lang attribute matches the language ranges held by the user agent locales." I do not get this definition. Is it about all elements named X having an xml:lang attribute that contains a value out of list Y? If so it might be more clear to say something like that.

There is no paragraph preceding the list of steps making it all somewhat confusing.

It should probably be a requirement that the document is _namespace_ well-formed. To prevent any confusion.

"If any of the following attributes are in error or invalid," is double and also somewhat recursive. E.g. invalid depends on the definition of in error. It is also unclear what "following attributes" refers to here.

"If any other attribute, in any XML namespace, apart from xml:lang, is used, then the attribute is in error and the user agent must ignore it." Is this not again stating what has already been stated? Duplicating requirements makes the specification very hard to read.

Marcos, All - I can't find a record of this email in the mail list
archive.

Begin forwarded message:

> From: "Penukonda Venkat (EXT-PSD-MSW/Boston)" <ext-
> venkat.penukonda@nokia.com>
> Date: June 2, 2009 11:59:34 AM EDT
> To: "public-webapps@w3.org" <public-webapps@w3.org>
> Cc: "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>
> Subject: [widgets] P&C LC#2 comment regarding icons
>
>
> Hi,
>
> Please refer to the latest Widget PnC spec http://www.w3.org/TR/
> 2009/WD-widgets-20090528/
>
> As per Section 8.10, icon element is not localizable using xml:lang
> attribute. It can only be folder-based localizable.
>
> Section 9, Step-7, Item# 7A is referring to xml:lang of icon
> elements to determine the valid icon list.
>
> Above two sections are contradictory. Most probably the section 9.7
> part need to be removed or corrected in the spec.
>
> Please let me know if you have any questions.
>
> -Thanks,
> -Venkat.
> ===============
> Venkat Penukonda
> Software QA Consultant
> Mobile: (978) 944-5879
>
>

Hi,

5.3 Zip Relative Paths has the following bugs:
* the ABNF for zip-rel-path uses "localized-folder", but only
"locale-folder" is defined
* the third rule for the conformance checker should be:
"A CC must inform the author of any Zip relative paths whose length
exceed 120 characters" (rather than "bytes").

http://www.w3.org/TR/widgets/#conformance-checker-behavior4 seems to be
misplaced under 7.2 instead of 7.3

There are quite a few aspects that make a zip archive an invalid widget
described in the processing section, but which are not highlighted as
conformance checker requirements, e.g:
* Step 1 labels an archive with a wrong media type as invalid
* Step 2 adds as cause of invalidity "split"-zips, and encrypted-zips
(beyond the already noted requirements on version and compression
method)
* requirements on the configuration file (XML well-formed, vocabulary
constraints)
(and probably more)

Dom

Hi,

I wrote a simple XSLT to extract the conformance requirements from the
Widgets spec [1], with the following output:
http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F%
2Fdev.w3.org%2F2006%2Fwaf%2Fwidgets%2Ftests%
2FextractTestAssertions.xsl&xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%
2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252Fwidgets%
252F

Based on these, here is a review of the Widgets spec based on
conformance requirements analysis:
* ideally, only the classes of products would appear as subjects of the
conformance requirements; e.g. "A folder may contain zero or more file
entries or zero or more folders" would be rephrased as "A valid widget
package may contain folders with zero or more file entries or zero or
more folders"; this would have two benefits: simplify the analysis of
conformance requirements for building test suites, and identify possible
ambiguities as to what is affected when the conformance requirements is
not respected; that said, I don't think it is crucial so feel free to
not go through all the conformance requirements if that's too much work
* similarly, conformance requirements that use the passive voice are
suspect (since they often don't tell to which class they apply)
* "For sniffing the content type of images formats, a user agents must
use the rule for Identifying the media type of an image" -> this assumes
that the user agent already knows the file it is sniffing is an image;
if that's true, the text should make it clear why, and if not, it should
probably be reworded to say that a user agent must sniff for images
format first
* rather than say "Reserved file names must be treated as
case-sensitive", I would amend the previous sentence to say "The
reserved file names table, below, contains a *case-sensitive*
list..." (and similarly for folder names)
* "If [...] the start file is not one that is supported by a particular
user agent, then the CC must inform the author": does that mean that a
CC need to know all the supported formats by all user agents? That seems
a bit excessive - I guess I can see cases where a conformance checker
could be configured to report knowledge on a special user agent, but
that would need to be made explicit, and clearly shouldn't be a must
* "a widget may attempt to access the feature identified by the feature
element's name attribute" I think the "may" here is not intended as a
conformance requirement, so it probably shouldn't be marked as such
* there is a spurious empty <em class="ct"></em> element in "A feature
can<em class="ct"></em> have zero or more <a href="#parameter0"
title="parameter">parameters</a> associated with it."
* "The steps for processing a widget package involves nine steps that a
user agent SHOULD follow" ; the "should" appear in upper case in the
source, while other conformance requirements are lower case
* "a user agent must to decompress" is not correct English
* "If a user agent encounters an unusable file entry, it must ignore
the file entry:" is ended by a colon, but followed by a new sentence
* "The algorithm always returns a string, which may be empty": again,
this "may" doesn't look like a conformance requirement so shouldn't be
marked as such
* "that must eventually be presented to the end-user" - I don't think
this is meant as a conformance requirement (e.g. a conformance checker
is a user agent, but will probably never present any of the widget
content to the end-user); I would reword it as "to be presented to the
end user"
* "an error condition can ask the user agent ignore an object" I don't
think error conditions can ask anything to anyone in general, so I would
rephrase it; I think "ignore" needs a preceding "to" too.

HTH,

Dom

1. http://dev.w3.org/2006/waf/widgets/tests/extractTestAssertions.xsl

Hi,

Oops, it looks like I have a few more points to make on path resolution.

These comments apply to the editor's draft 11 June 2009 version of the
Widgets 1.0: Packaging and Configuration specification.

Comments apply to the "Rule for finding a file within a widget package"
section in 9.1 Processing rules:
http://dev.w3.org/2006/waf/widgets/#rule-for-finding-a-file-within-a-widget-

Comment 1 is minor.
Comment 2 is more important in my view.
Comment 3 is not a big deal, although I think the spec introduces
complexity where it's not needed.


Comment 1: relative can't be absolute
-----
Step 3: "meaning that the path is an Zip absolute path"

How can path be a Zip absolute path? It is defined in step 1 as the "Zip
relative path to the file entry being sought". A zip relative path
cannot start with a "/".

Updating to definition of "path" to the "valid path to the file entry
being sought" should solve the problem (valid path = zip-rel-path |
zip-abs-path)



Comment 2: links resolution in e.g. start file
-----
The specification implies but does not define how links in documents
other than the configuration document are to be handled (or did I miss
something?). In particular, how is a user agent supposed to resolve
relative links to packaged files that appear in the start file?

If the "rule for finding a file within a widget package" is to be
followed, the behavior is going to be "strange" in some cases. Consider
the case of a configuration document whose start file is defined as:
/startfolder/index.html

If index.html then uses relative paths to include an image, e.g.
"bar.gif", I would expect the user agent to behave as a regular Web
browser, and resolve "bar.gif" in the same folder as "index.html", i.e.
"/startfolder/bar.gif". Leaving localization aside for a second, step 5
of the rule for finding a file within a widget package will be reached,
and that means "bar.gif" will actually be searched "at the *root* of the
widget package", and not in "/startfolder". That's weird.

I think you should explain how to construct the Zip "valid path" of a
file entry from a relative path that may appear in a document and the
path of the document in question, i.e. from "bar.gif" to
"/startfolder/index.html" in the previous example.



Comment 3: localization and absolute URIs
-----
We more or less already exchanged emails on that, but... I don't
understand the need to have absolute paths bypass localization.

Consider the two examples below:
1. a config document that contains a <content
src="startfolder/index.html" /> directive
2. a config document that contains a <content
src="/startfolder/index.html" /> directive

I think people are used to using relative and absolute paths in links
interchangeably. Since the config document is at the root of the widget,
I would expect the two examples to have the same effect. Here, if the
widget's package contains a locales/fr/index.html, it may be used in the
first case (provided "fr" is in user agent locales of course), but it
won't ever be used in the second case.

I realize that when an absolute path is treated the same way as a
relative path, the "Complex example" of 8.4 Localization Examples:
http://dev.w3.org/2006/waf/widgets/#complex-example
... cannot be implemented as such in practice. I think that's fine,
there should not be any way for something in a "locales/[LANG]" folder
(or wherever else for that matter) to bypass the localization algorithm.
Having one complicates things more than anything else, IMHO.


Francois.

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?

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 1 Jun 2009 14:25:18 +0300
Message-Id: <A3CE0D9D-5C36-48AC-863C-ADD56CBE8659@iki.fi>
To: public-webapps <public-webapps@w3.org>

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?

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

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

9:01 AM me: hey, you won't like this, but... I think we botched the
l10n stuff :). The problem is that the design is based on individual
resources, which is wrong. Negotiation should really be done at the
Package level. This is one of those things where thinking HTTPish
screws you over. A user thinks about a web application or widget as a
single resource. That there are multiple subresources isn't
interesting to a user. So the right algorithm is: 1. collect the full
list of all locales for which the package is partially localized. 2.
build the list of user requested locales using the algorithm we
defined. 3. Use the first matching locale between (1) and (2). 4. Deal
with fall back. I think 4 involves telling Authors that if they want
to be able to use a /locales/en/ image in /locales/en-us/ then they
need a /locales/en-us/images.css that pulls in /locales/en/bird.jpg --
however, it's probably best just not to allow it at all.
http://en.wikipedia.org/wiki/Coccinellidae is something I encountered
@HEL flying to the F2F, I call it a Lady Bug, but the label (embedded
in what I'll call a "picture" said "Lady Bird", and I though it was a
mistake, so i took a "photo" of it to post to my friends. If I posted
the photo as /en/, the GB/AU/... friends would not get it). Similarly,
Nokia has this gem:
http://www.webwizardry.net/~timeless/w7/nokia%20communication%20centre%20-%20Use%20the%20Calendar%20view%20in%20Nokia%20Communication%20Center%20to%20manage%20your%20device%20calendar%20for%20example%20by%20creating%20editing%20or%20deleting%20calendar%20entries.png
which is because they tried to be clever about sharing a picture
between the en-GB installer and the en-US installer.
  The results are terribly embarrassing
9:02 AM Put another way. The goal of localization should be twofold:
1. allow the user to express a preference. 2. enable the author not to
make the mistakes that Nokia has made
9:03 AM mixed content such as my Lady Bug/Bird example and Nokia's
myriad examples (the classic one being their Flag example, url
available for archival purposes later; the more modern example being
centre/center).

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.

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

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

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.

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.

EDITORIALs

6.5
via a content elements src attribute.
should be
via a content element's src attribute.

"A default start file must appear at either the ..."
"A default start file" is not an anchor.


6.6
Authoring guideline
"If using [SVG] as an icon format and one intends it to be animated, use declarative animation."
should be
"If using [SVG] as an icon format with an intention for it to be animated, use declarative animation."

6.7
"Over the wire (e.g. over HTTP)..."
Maybe something more descriptive could be invented here, since recently the Web content gets delivered wireless and over HTTP?

6.8
"A widget file extension is the text string .wgt in any case form..."
What about:
A widget file extension is the text string that case-insensitively matches the string ".wgt".

7.
All files and folders, except digital signatures ...
should be
All files and folders, except for the digital signatures ...

7.2
This sections presents three ...
should be
This section presents three ...

The purpose of this "fallback" model is to reduce then number of ...
should be
The purpose of this "fallback" model is to reduce the number of ...

In this case, to find find the ...
should be
In this case, to find the ...

7.3
whose folder-name case-sensitively match the string ...
should be
whose folder-name case-sensitively matches the string ...

________________________________________

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.

EDITORIALs

8.3
Some general rule for how attributes are to be processed a user agent or conformance checker are also ...
should be
Some general rule for how attributes are to be processed by a user agent or a conformance checker are also ...

... given the processing rules that type of attribute.
should be
... given the processing rules for that type of attribute.

Version attribute
"The value of a version attribute is an arbitrary string (possibly empty) that denotes a software version identifier."
What is software?
8.5 says
version
A version attribute that specifies the version of the widget. It is optional for authors to use this attribute.
Both shall be aligned.

Numeric attribute
a)
consists of one of more ...
should be
consists of one or more ...
b)
Maybe ABNF could help in this definition?

Keyword attribute
must not use case insensitive comparisons.
should be
must not use case-insensitive comparisons
[It would be good to perform a check for all "case-sensitive"/"case-insensitive" instances whether they are written in the same

manner.]

in which is it used, so the rule for hoe to retrieve
should be
in which iT iS used, so the rule for hoW to retrieve

Keyword list attribute
Maybe ABNF could help here?

An attribute defined as taking one or more keywords as values, which ...
should be
An attribute defined as taking one or more keywords as value, which ...

Boolean attribute
Maybe ABNF could help for true and false?
"... the feature element's..."
should be
"... the <feature> element's..."

Path attribute
A valid path is one that matches the the production ...
should be
A valid path is one that matches the production ...

A zip-abs-path is invalid in a the file name filed of a file entry.
should be
A zip-abs-path is invalid in the file name field of a file entry.

8.4
... primary language of an element, its attributes, and its descendent nodes.
should be
... primary language of an element, its attributes and its descendent nodes.

its:dir
i.e., ltr, or rtl, or lro, or rlo
should be
i.e., ltr, rtl, lro or rlo

8.5
view port
should be
viewport

"View port and view mode are defined in the [Widgets-Views] specification."
I cannot find the definition of either view port or viewport in [Widgets-Views].

8.7 and others
Starting always with "The ... element" or with "A/An ... element"? Just for consistency.

8.8
regardless of value of
should be
regardless of the value of

8.9
Localized license shouldn't be used
should be
Localized license should not be used

... the user agent should allow users the ability to view ...
should be
... the user agent should provide the users the ability to view ...

8.10
If the file pointed to by the src attribute is a vector graphic format ...
could be
If the file pointed to by the src attribute contains an icon in a vector graphic format ...

8.11
The allowed values are any name of a character set listed in ...
should be
The allowed value is any name of a character set from those listed in ...

(a user agent are required ...
should be
(the user agents are required ...

________________________________________

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.

8.12
in which case a user agents that
should be
in which case a user agent that

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.
should be
In other words, the required attribute denotes WHETHER a feature is absolutely needed by the widget to function correctly,
and WHETHER without the availability of this feature the widget serves any useful purpose or WHETHER it will execute properly.
or
In other words, the value "true" of 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.

... meaning that the feature must be made available to the widget by the widget at runtime.
should be
... meaning that the feature must be made available to the widget at runtime.
or
... meaning that the feature must be made available to the widget by the user agent at runtime.

8.13
"Outside the context of a feature element, a param element does not represent anything and a user agent must ignore it."
This sentence seems redundant, because the "Context in which this element may be used:" part is normative enough.

8.14
"Unless an end-user explicitly requests that these values be reverted to the values as declared in the configuration document, a

user agent must not revert to these values on subsequent initialization of the widget."
More information about management of these values is needed. What is reverting? How can the end-user explicitly request that these

values are reverted to the value from config.xml? This is UI/UX aspect that needs specification.

8.15
I suggest to move this section before section 8.5, because it defines what "Localizable" (used from 8.5) means.

8.16
The its:dir attribute and the <its:span> element can each be used as a child of ...
should be
The <its:span> element with the its:dir attribute MAY each be used as a child of ...

9.
Rule for getting a list of keywords from an attribute
There are dropping and chopping (operations not clearly defined). Maybe the algorithm could be defined more precisely?
It returns a list, takes a string as input.
So the first suggestion is to use different variable name from the temporary "result" and the actual "result".

9.1 Step 7
"During the processing of a configuration document, an error condition can ask the user agent ignore an object (e.g., a file or a

DOM node)."
Not sure what it means.

________________________________________

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.

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.

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.

Error in ABNF:
localized-folder vs. locale-folder

Error with ABNF
utf8-chars = safe-chars / U+0080 and beyond
"and beyond" does not fit here
Section 2. of RFC2279 shows that all UTF-8 characters above U+0080 are encoded with byte values over 0x80.
So utf-8 production equals to cp437 production on the byte level within the context that is important for us.
So both productions can be equalized and removed, since allowed-char may be used.
I think the problem is similar to this one about encoding (I just had a brief look on it):
http://lists.w3.org/Archives/Public/public-html/2009May/0643.html

Error with ABNF
cp437-chars = safe-chars / x80-FF
should be according to RFC2234:
cp437-chars = safe-chars / %x80-FF

Due to many issues I would rewrite the whole ABNF as follows.
ABNF issues, additionally to the above, are:
1. plural form used for just "one-of" value
2. the zip-rel-path may have problems with existence, since all productions are optional. The below format seems equal and is
shorter
3. the production of file-name is wrongly specified, since there file-extension could appear up to 254 times in a file name
4. I am not sure whether the file extension could be more than 3 chars or not in the existing ABNF?
If so, the actual file name shall match 2 rules simultaneously, e.g.:
file-name1 = 1*allowed-char [ "." 1*allowed-char ]
file-name2 = 1*254 ( allowed-char )
Matching of those 2 rules is not expressible in ABNF, so prose would be needed.

New ABNF (problem of file extension length as above still remains):
**************
A valid Zip relative path is one that case-insensitively matches the production of Zip-rel-path in the following [ABNF] that
operates on bytes, not on characters, i.e. after any encoding (CP437 or UTF-8) has been applied:

zip-rel-path = [ locale-folder ] [ *folder-name ] [ file-name ]

locale-folder = "locales" "/" Language-Tag "/"
folder-name = file-name "/"
file-name = base-name [ file-extension ]
file-extension = "." 1*3 ( allowed-char )

base-name = 1*250( allowed-char )
allowed-char = safe-char / %x80-FF
safe-char = ALPHA / DIGIT / SP / "$" / "%"
/ "'" / "-" / "_" / "@"
/ "~" / "(" / ")" / "&" / "+"
/ "," / "." / "=" / "[" / "]"
**************

Authors need to keep path lengths below 250 bytes. Unicode code points can require more than one byte to encode, which can result in
a path whose length is less than 250 characters.
should be
Authors need to keep path lengths below 250 bytes. Unicode code points may require more than one byte to encode a character, which
can result in a path whose length is less than 250 characters to be represented in more than 250 bytes.

UTF8-chars
should be
utf8-chars or utf8-char or something new (after the ABNF is updated) .

________________________________________

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.

9.1
Step 1
The section is about acquiring the Zip archive.
It is however only about data transfer protocol. What about simple files in the filesystem?

Step4
This step only applied to user agents ...
should be
This step only is applied to user agents ...

Step7
What to do when more then one ...
should be
What to do when more than one ...

For example, assume the user agent's locales<http://dev.w3.org/2006/waf/widgets/#user-agents-locales> only contains the ...
should be
For example, assume the user agent's locales<http://dev.w3.org/2006/waf/widgets/#user-agents-locales> only contain the ...

However, if the user agent's locales<http://dev.w3.org/2006/waf/widgets/#user-agents-locales> was "*",
should be
However, if the user agent's locales<http://dev.w3.org/2006/waf/widgets/#user-agents-locales> contained only "*",

type whose xml:lang<http://dev.w3.org/2006/waf/widgets/#xmllang> attribute match the language
should be
type whose xml:lang<http://dev.w3.org/2006/waf/widgets/#xmllang> attribute matches the language

can ask the user agent ignore an object
should be
can ask the user agent to ignore an object

is left up-to the
should be
is left up to the


"5 Otherwise,

the element is a widget<http://dev.w3.org/2006/waf/widgets/#widget0> element:"
Not very clear structure.
It should probably be:
"Otherwise, if the element is a widget<http://dev.w3.org/2006/waf/widgets/#widget0> element:"

"Let root element be the documentElement of doc."
documentElement could be referenced to DOM3


be the result of apply the
should be (a few times)
be the result of applying the

then the attribute is in error<http://dev.w3.org/2006/waf/widgets/#in-error> the user agent must ignore<http://dev.w3.org/2006/waf/widgets/#ignore> it.
should be
then the attribute is in error<http://dev.w3.org/2006/waf/widgets/#in-error> and the user agent must ignore<http://dev.w3.org/2006/waf/widgets/#ignore> it.

"Otherwise, continue this algorithm."
Seems not needed.

Content element:

If the type<http://dev.w3.org/2006/waf/widgets/#type0> attribute is used,
could be
If the type<http://dev.w3.org/2006/waf/widgets/#type0> attribute is present,

If the charset<http://dev.w3.org/2006/waf/widgets/#charset0> attribute is used,
could be
If the charset<http://dev.w3.org/2006/waf/widgets/#charset0> attribute is present,

If a required<http://dev.w3.org/2006/waf/widgets/#required> attribute is used,
could be
If a required<http://dev.w3.org/2006/waf/widgets/#required> attribute is present

... ignore this element/attribute. Stop processing this element ...
Here, better linking to the preceding "if" could add clarity. A "." (dot) and imperative mode may result in misunderstanding (there are many instances of this case).

Step 8
then skip this Step and
should be
then skip this step and

If potential-start-file is null or an error, ignore<http://dev.w3.org/2006/waf/widgets/#ignore>
should be
If potential-start-file is null or in error, ignore<http://dev.w3.org/2006/waf/widgets/#ignore>
But potential-start-file cannot be in error, since there is no such assignment.

Let start file content-type<http://dev.w3.org/2006/waf/widgets/#start-file-content-type> be the media type<http://dev.w3.org/2006/waf/widgets/#media-type0> given in the second column of the default start files<http://dev.w3.org/2006/waf/widgets/#default-start-files> table.
How to choose the item from that columnt?

Stopped at Step 8. To be continued.

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.

EDITORIALs and Global stuff

Unify "inform an" vs. "inform the" throughout the full document.
Unify i.e. (i.e.,) and e.g. (e.g.,) to follow fully either American- or British-English.
Should not the RFC2119 terms in authoring guidelines be also in uppercase?
What is the normative status of the authoring guidelines?
Term API is not defined.
Maybe <...> notation could be used for all elements, not only for <its:span>?
Zip or zip could be used consistently within the document.

1.4
Could this section (and the similar content from the family specs) be moved to a separate document?

3.2
its:span
should be
<its:span>

4.
assists them making
should be
assists them in making

5.
.Zip file
may be
.zip file

5.2
minimum version supported version
should be
minimum supported version

the the CC MUST
should be
the CC MUST

5.3
it is recommended that a user agent internally treat all zip-relative
should be
it is recommended that a user agent internally treats all zip-relative


________________________________________

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.

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.

Hi Marcos, All,

These are a few editorial comments to the latest P&C ED.

6.6 Icons and 9.1/Step7/<icon>

Step7 requires only a valid path for src attribute:
"Let path be the result of applying the rule for getting a single attribute value to the src attribute. If path is not a valid path, then the user agent must ignore this element and its attributes. Proceed to the next element in the elements list."
whereas 6.6 is more restrictive and says:
" An icon must be located either at the root of the widget package or at the root of a locale folder."

Therefore I suggest to refer to 6.6 from Step7 is some way, e.g. by creating a new rule for icon path or by just adding some prose in Step7, like:
"Let path be the result of applying the rule for getting a single attribute value to the src attribute. If path is not a valid path or does not fulfill the restriction from 6.6, then the user agent must ignore this element and its attributes. Proceed to the next element in the elements list."

7.12 Note
"A user agent can expose a feature through, for example, an API, in which case a user agent that supports the [Widgets-APIs] specification can allow authors to check if a feature loaded via the hasFeature() method." (Non-normative)
[Widgets-APIs] spec says nothing about loading features, at least now.
It seems not to be agreed that hasFeature() method would be used for that purpose,
specifically because hasFeature() is used in DOM to check for - static IMHO - existence of some module/functionality/feature, and feature loading that is meant within P&C is of dynamic nature.

So I suggest removing that sentence from the note in order not to create a de-facto standard.

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.

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.

On Tue, Jun 2, 2009 at 3:50 PM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> wrote:
> 9.1
> a user agent must to decompress ...
> should be
> a user agent must decompress ...

fixed

> ... instructions on how to extract a file for Zip archive.
> should be
> ... instructions on how to extract a file from Zip archive.

fixed

> The rule for dealing with an invalid Zip archive is described in this section.
> </p><p> could follow this sentence as in the previous subsection.



> Rule for finding a file within a widget package
>
> If none if found
> should be
> If none is found

fixed

> ... the name of the path (
> could be
> ... the path (

fixed

> Rule for finding a file within a widget package: algorithm
>
> 3.B If path points to a file entry  within the widget package, then return the corresponding file.
> should be
> 3.B If path points to a file entry  within the widget package, let file be the result of applying the rule for extracting file data from a file entry to path.

> And maybe jump to 4.B or terminate as 4.B and 4.C do.

I added a new 3.C:

"If file is a processable file, then return file and terminate this algorithm. "

> An unusable file entry is one where by any of following conditions occur/apply ...
> should be
> An unusable file entry is one where any of following conditions occur/apply

I rewrote that section, as it was a bit of a mess. It now just returns
true or false.

> Rule for Getting Text Content
>
> "Let input be the [DOM3Core]  Element to be processed."
> Unclear: Where does the [DOM3Core] Element come from?

Step 7, "Let doc be the result of loading the widget config doc as a
[DOM3Core] Document using a [XMLNS]-aware parser."

> Probably some assignment like:
> "the element to be processed MUST be interpreted as [DOM3Core] Element"
> would help.

Removed the reference. Added your text:

"The rule for getting text content is given in the following
algorithm. The element to be processed must be interpreted as a
[DOM3Core] Element. The algorithm always returns a string, which may
be empty."

> "Return the value of the textContent property for input."
> Where does the textContent property come from? [http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent ? ]
>

right

> " There may be implementation-specific limits on the range of integers allowed, and behavior outside such limits is undefined."
> What about interoperability, again.

See Robin's email, again.

> Rule for Identifying the Media Type of an Image
>
> ... the first bytes of the file matches one of ...
> should be
> ... the first bytes of the file match one of ...

Fixed

> ... in hexadecimal column of ..
> and
> ... in the second column ...

Right, I changed it to the the "magic number column" and "media type column"

> both should be revisited, since the column names seem not to match the text. (Are the columns indexed from 0?)
>

Fixed.

> "A 0 word following by a 1 word,"
> Endianness is unclear.

Removed "A 0 word following by a 1 word".

> The rule for identifying the media type of a file are given by ...
> should be
> The rule for identifying the media type of a file is given by ...

Fixed

> 1. Let file be the file to be processed. ...
> could be
> 1. Let filename be the name of the file to be processed.
> 2. If filename includes a file-extension, attempt ...

I think file is correct here.

> attempt to match the file-extension to one in the first column
> should be
> attempt to match the file-extension to one of the strings in the first column

Fixed

> Comments as above for "Rule for Identifying the media type of a file".
>

As above.

I'm forwarding the following comments on behalf of Martin Nilsson, of
Opera Software, with his permission, to be addressed as part of the LC
review.

Kind regards,
Marcos

======
Section 5.3: Why not mandate all paths to be UTF-8? I really hate the
notion of "If an author chooses to use cp437-chars or the UTF8-chars,
they should thoroughly test their widgets on various platforms prior to
distribution". No, it should work if you follow the specification.

Secondly, why case insensitive? And if so, how would a user agent treat
an archive with several entries that just differ in case?

This also looks redundant

"A CC must inform the author of any Zip relative paths whose length
exceed 250 bytes

A CC must inform an author of any Zip relative path whose length exceeds
120 bytes."

Section 9.1: The rules for identifying the media type of a file doesn't
explicitly mention that it could have been explicitly set from the
configuration file. This is mentioned in the section below that
references this, but perhaps a mention for clarity would be good.

As a sidenote it looks like it's not possible to define the mime type of
other files than the start page. I find that a big oversight, if true.

Another thing. In the Zip Support section of 3.1 it says that it is
optional for a user agent to support "Any decompression algorithm, other
than [Deflate] and Stored (no compression) [ZIP]." However in 5.1 it is
stated that "Only compress Zip archives with [Deflate] or Stored (no
compression); other compression formats will cause the widget package to
be treated as an invalid Zip archive.".

So you can optionally select something different than deflate and store,
but that will cause the package to be invalid?