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