Re: [widgets] Seeking comments on Last Call WD of Widgets: APIs and Events spec; deadline 15 Sept 2009

Metadata Attributes and the Storage Area
================================
I don't think its clear from the spec if metadata attributes are 
within the scope of widget.preferences and must be stored in the same 
storage area.
E.g. Does widget.preferences.getItem("name") == widget.name? if not, 
then why does a script calling widget.preferences.setItem("name", 
"blah") need the UA to throw an exception?
Some options:
1. metadata attributes must be treated as equivalent to preferences, 
and in fact should be able to be accessed in the same manner;
2. metadata attributes are not the same as preferences, and their 
storage should not conflict with preferences. Therefore preferences 
with the same keys as metadata attribute names are fine.
3. metadata attributes should not be made accessible using 
widget.preferences, but must be treated as being stored in the same 
storage area, and potentially have conflicting keys; therefore 
preferences with the same keys as metadata attribute names are 
disallowed.
(We currently implement using option 1, but would be happy with option 
2. I don't think option 3 has much merit)
Read-only Metadata Attributes
========================
For read-only attributes, I note that there is no actual conformance 
statement. I suggest adding a nice broad one in 6.1, to allow more UAs 
to reach conformance:
"A User Agent SHOULD take reasonable steps to prevent author scripts 
from modifying Metadata Attributes. Where it is not practical for a 
User Agent to prevent an author script setting or clearing a Metadata 
Attribute during runtime, the User Agent MUST NOT persist any such 
modifications for further instantiations of the Widget."
So a web browser implementing the spec can declare the attributes in 
the Window and make them read-only as it controls the environment, and 
Wookie can just not save any changes beyond the scope of the current 
browser session.
Section 5.1 and "syntactic sugar"
==========================
Section 5.1, para 4 reads:
"Upon invocation of the setItem() or removeItem() method by an author 
script on a protected key, user agent must throw a 
NO_MODIFICATION_ALLOWED_ERRexception. The NO_MODIFICATION_ALLOWED_ERR 
is defined in the [DOM3Core] specification."
OK, this is fine, we can implement this. However, what about:
widget.preferences.blah = "new value"; // where "blah" is a read-only 
key
We really don't have any way to prevent this happening or throwing an 
exception. Luckily for us the conformance statement above doesn't 
mention it, which means we don't have to!
However I don't think this was the intention - it just shows one of 
the problems with the "syntactic sugar" interpretation of WebStorage. 
For any UA other than a browser, you really don't get the option to 
protect exposed javascript properties.
I suggest changing the example in 6.4.2 to use getItem(), and adding a 
note re: alternative syntax.
Personally I'd rather exclude them for the sake of interoperability. 
If not, 5.1 para 4 & 6.4 para 4 need changing to cover semantically- 
equivalent operations using alternative syntaxes; however unless the 
conformance requirement is reworded as per my suggestion above for 
read-only metadata attributes, we probably have to give up any hope of 
ever conforming to the spec :-(
S