Fwd: Widget Addressing Timescales and Test Cases.

RE: [widgets] Minutes from 30 October 2008 Voice Conference

Resolving the general topic of ZIP-based packages and URI references within them on the webapp mailing
list doesn't seem practical, because those who need to review the package/URI issue are likely not
interested in wading through the mass of other email on other unrelated topics within WebAPP WG.

I don't understand why setting up a separate mail list/archive/issue list on the specific topic is a
lengthy process, it mainly requires the will to take the need for coherence seriously.

If resolving this in a timely fashion is important to you (as you seem to indicate by invoking "time scope")
then perhaps you might want to respond more quickly.

Larry

-----Original Message-----
From: Marcos Caceres [mailto:marcosscaceres <at> gmail.com]
Sent: Friday, November 21, 2008 3:29 AM
To: Larry Masinter
Cc: Arthur Barstow; Jon Ferraiolo; Richard Cohn; Bill McCoy; Henry.Story <at> Sun.COM; Michael Stahl;
www-archive <at> w3.org; Svante Schubert; eduardo.gutentag <at> oasis-open.org; Philippe Le Hegaret; Carl
Cargill; Stephen Zilles; www-tag <at> w3.org; public-webapps
Subject: Re: [widgets] Minutes from 30 October 2008 Voice Conference

Hi Larry,
On Fri, Oct 31, 2008 at 3:01 PM, Larry Masinter <masinter <at> adobe.com> wrote:
> Hi all,
> I think there is considerable interest in a broad community in the topic of
> ZIP based packages, specifically MIME types for them and intra-package URI
> references within them, and possibly for standardizing metadata as well.
>
> Procedurally, I don't think it is appropriate to attempt to resolve these
> issues in the WebAPP working group, if only because a number of the affected
> groups have little additional overlap with WebAPPS. I know the W3C TAG has
> discussed the URI issues at some point.  I'm not sure if the overhead of
> starting a new W3C working group focused specifically on this topic is too
> high, but if so, an IETF activity with W3C participation might be a way of
> getting broader participation, as well as getting additional IETF
> involvement in the MIME/URI issues.
>

Although I agree that starting an independent group might be a good
idea, I fear that the administrative overhead of getting everything
set up is beyond the time scope for the Widgets Work (which we want to
get to LC by end of this year). To keep the work moving forward, I
propose that interested parties continue to work with WebApps, through
our public mailing list, on the problem. We could continue to push for
an independent group and then migrate whatever gets done in WebApps to
a new group or spec.

WebApps will continue to work on the problem regardless. So I again
encourage people to work with us on the problem and put forward ideas
about how we could solve this.

Kind regards,
Marcos

--
Marcos Caceres
http://datadriven.com.au

Re: [XHR] security issue with spec's "same-origin" and the Document pointer

On Fri, 21 Nov 2008 17:28:34 +0100, Hallvord R. M. Steen  
<hallvord <at> opera.com> wrote:
> var xhrConstructor = iframe.contentWindow.XMLHttpRequest;
> iframe.src='http://attackee.example.com/';
> .
> .
> var xhr = new xhrConstructor();
>
> When the constructor is invoked here, the associated document of its  
> associated window object is not safe to do same-origin comparisons  
> against. I've tested this in the main 4 engines, and they all protect  
> against this exploit but as far as I can see someone implementing the  
> spec as it's written would end up vulnerable.

Why would the SECURITY_ERR exception not be thrown during the open()  
method invocation as the specification requires?

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Re: [Selectors-API] IDL namespace

Cameron McCormack wrote:
> Kartikaya Gupta:
>> What namespace does the Selectors-API IDL belong to? This determines
>> the java package (org.w3c.dom.???) that the NodeSelector interface
>> will go in, and is needed for java implementations. Even if it's just
>> the top-level namespace (i.e. the org.w3c.dom package) a note to that
>> effect would be handy.
> 
> Yes I think the dom module (and hence the org.w3c.dom Java package) is
> appropriate.  Lachy, the method for mapping IDL modules to Java packages
> in Web IDL isn’t finalised yet.  But the interface can be placed in the
> dom module for now, at least:
> 
>   module dom {
>     interface NodeSelector {
>       // …
>     };
>   };

It seems from the Java bindings section of Web IDL that the way to 
define modules and how they're mapped to Java packages isn't yet very 
stable.

http://dev.w3.org/2006/webapi/WebIDL/#java-modules

I'm hesitant to include the module declaration in the IDL at this stage. 
  Although I suppose I could and then just update it if WebIDL changes. 
  If I did so, is there anything else I would need to specify in the 
prose for this?

--

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Liveness versus NodeList

Stewart Brodie wrote:
>> This is considered to be a bug in the DOM Core specs, which will
>> hopefully be fixed by Web DOM Core, which is a proposal Simon Pieters is
>> working on.
> 
> You will still need a new type, as I don't see how you can possibly change
> the existing behaviour so dramatically under the feet of existing content.

The change will just be to remove the requirement that all NodeLists be 
live.  Specific methods and properties that return NodeLists will define 
whether their NodeLists are live or not on an individual basis.  No 
behavior change will be observable for existing implementations.

-Boris

Re: [selectors-api] Liveness versus NodeList

Stewart Brodie wrote:
> You will still need a new type, as I don't see how you can possibly change
> the existing behaviour so dramatically under the feet of existing content.
> 
> I would not like to lose the liveness property of node lists, as it would 
> make NodeList objects incredibly memory inefficient if we had to construct 
> the entire node list at NodeList construction time, too.

We are not changing the behaviour of all NodeLists, just reusing the 
same interface for both static and dynamic lists.

--

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Names of querySelector() and querySelectorAll() methods

On Nov 18, 2008, at 9:32 PM, Gavin Kistner wrote:
> I find these names rather cumbersome and not very self-explanatory.
>
> Though it may be far too late for this suggestion, I would suggest  
> that they should be something such as:
>
> findNode()/findNodes() or findNode()/findAllNodes()
> selectNode()/selectNodes() or selectNode()/selectAllNodes()
> findBySelector()/findAllBySelector()

Er, please replace all instances of Node with Element in the above.  
Dunno what I was smoking.

And 2 more:
elementFromSelector()/elementsFromSelector()

[selectors-api] Matching subtrees or not

Section 6 states:
"The querySelector() method ... must ... return the first matching  
Element node ***within the node’s subtree***." [1]
"The querySelectorAll() method ... must ... return ... all of the  
matching Element nodes ***within the node’s subtree***..." [2]
(Emphasis mine.)

In conflict, Section 8 (Examples) states:
"Even though the method is invoked on an element, ***selectors are  
still evaluated in the context of the entire document***. In the  
following example, the method will still match the div element's child  
p element, even though the body element is not a descendant of the div  
element itself." [3]
(Emphasis mine.)

As Section 8 is non-normative (being an example, as covered under  
section 2), I assume that it is wrong. I agree with the specifications  
as stated in section 6: invoking the methods on a node should only  
match against the subtree of that node (or possibly the node and its  
subtree), not the entire document.

[1] http://www.w3.org/TR/2008/WD-selectors-api-20081114/#queryselector
[2] http://www.w3.org/TR/2008/WD-selectors-api-20081114/#queryselectorall
[3] http://www.w3.org/TR/2008/WD-selectors-api-20081114/#examples0

[selectors-api] First element example

The second example in section 8 uses the following code:
   var x = document.querySelector("#foo, #bar");

It goes on to rather explicitly state, "In the sample document above,  
it would select the div element with the ID of foo because it is first  
***in document order***" (my emphasis).

Nonetheless, I believe the example code could help clarify the  
situation further by being changed to:
   var x = document.querySelector("#bar, #foo");

This, along with the assertion that div#foo is the value of x, would  
ensure that the casual reader might not mistakenly believe that the  
order of selectors in a group affects the ordering of the results.

[widgets] Agenda for 20 November 2008 Voice Conference

Below is the draft agenda for the November 20 Widgets Voice  
Conference (VC).

Inputs and discussion on the agenda topics before the meeting is  
encouraged.

Logistics:

   Time: 07:00 Boston; 13:00 Paris; 21:00 Tokyo
   Duration = 60 minutes
   Zakim Bridge +1.617.761.6200, conference 9231 ("WAF1")
   IRC channel = #wam; irc.w3.org:6665
   Confidentiality of minutes = Public

Agenda:

1. Review and tweak agenda

2. Announcements

3. DigSig spec:

a. Issue 19 "Widgets digital Signatures spec does not meet required  
use cases and requirements": what needs to be done to address and  
close this issue?
   <http://www.w3.org/2008/webapps/track/issues/19>

b. Action-273 "Do you object to the removal of the  
WidgetSignatureInfo element?"; Thomas
   <http://www.w3.org/2008/webapps/track/actions/273>

c. Action-275 "What is our lifecycle, revocation model?"; Mark
   <http://www.w3.org/2008/webapps/track/actions/275>

d. Action-208 "Contribute security considerations for decompression  
and signature validation"; Thomas
   <http://www.w3.org/2008/webapps/track/actions/208>

e. Action-224 "Work with Marcos to flesh out the details of the  
processing model for multiple signatures"; Mark
   <http://www.w3.org/2008/webapps/track/actions/224>

f. Issues in Section 7 "Procedure for Verifying a Digital Signature  
Document":
   <http://dev.w3.org/2006/waf/widgets-digsig/#procedure>

g. Questions for XML Security WG:
   <http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/ 
0242.html>

4. APIs and Events spec:
   <http://dev.w3.org/2006/waf/widgets-api/>

a. Red Block Issues in Section 2: add some context so reader can  
understand the issue;

b. Action-233 "Research the Widget object's preference attribute to  
make sure it uses the correct type"; Arve
   <http://www.w3.org/2008/webapps/track/actions/233>

c. Action-232 "Check the API spec for compliance with the Web IDL  
spec"; Arve
   <http://www.w3.org/2008/webapps/track/actions/232>

d. Plan for FPWD

5. AOB

setRequestHeader underspecified - setting "Accept" header as an example

I've found a site that requires that any UA default value is overridden  
with the new value when using setRequestHeader('Accept', ..).

(For reference: the site is mail.163.com, it uses XHR extensively to fetch  
data and sets Accept header to "text/javascript" to fetch JSON content. If  
that value is appended to the UA's internal list instead of replacing it  
the server returns XML instead of JSON, which doesn't go down well with  
the JSON "parsing" - i.e. eval() - they put the data through.)

The spec says about "setRequestHeader()":

> If the header argument is in the list of request headers either use  
> multiple headers, combine the values or use a combination of those  
> (section 4.2, RFC 2616).

I think this needs to be way more specific. We probably need to verify  
what existing UAs do for actual header values, and make some sensible  
rules from that.

--

-- 
Hallvord R. M. Steen
Core JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience