RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news 
is we're nearly done. It's going through a final peer-review to make sure we've 
received feedback from experts in the company including our security gurus. 
(Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. 
Thanks for waiting.

> -Original Message-
> From: Arthur Barstow [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); public-
> [EMAIL PROTECTED]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.

Re: Note for DOM L3 Core SE

[Maciej Stachowiak]

On Jun 6, 2008, at 2:20 PM, Travis Leithead wrote:



While implementing some improvements to getAttribute in IE8, we  
actually checked in code that is conformant to what the spec says  
about the return value:


Return Value
DOMString
The Attr value as a string, or the empty string if that attribute  
does not have a specified or default value


Once this code was in, we immediately hit app and site compat  
problems because we always returned a string--an empty string--if  
the "attribute [did] not have a specified or default value".


As it turns out in practice, all browsers actually implement this a  
slightly different way: they return the value as a string, or null  
if the attribute does not have a specified or default value. In  
other words, if there is no entry for the requested attribute in the  
NamedNodeMap, then null is returned.


IE8 is being fixed to be conformant with what everyone else has  
implemented, I just thought I would pass this along to whomever is  
doing the DOM L3 Core Second Edition so that it might be recorded in  
that spec, an errata, or so that we can discuss.


Anne and I suggested an errata for this a few years back, but the DOM  
folks were not receptive at the time, out of consideration for server- 
side Java DOM implementations:


http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0011.html
http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0025.html

See the thread for more discussion.

I also at the time raised another compatibility issue that I thought  
should be fixed in errata:


http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0024.html

The short version is that DOM forbids inserting nodes into a different  
document than their ownerDocument, but browsers allow it (in at least  
some cases).



These two issues are Safari's only failures in the official DOM Level  
1 Core test suite. I believe neither of these failures can be fixed  
without significantly breaking web compatibility.


Regards,
Maciej

Note for DOM L3 Core SE

[Travis Leithead]

While implementing some improvements to getAttribute in IE8, we actually 
checked in code that is conformant to what the spec says about the return value:

Return Value
DOMString
The Attr value as a string, or the empty string if that attribute does not have 
a specified or default value

Once this code was in, we immediately hit app and site compat problems because 
we always returned a string--an empty string--if the "attribute [did] not have 
a specified or default value".

As it turns out in practice, all browsers actually implement this a slightly 
different way: they return the value as a string, or null if the attribute does 
not have a specified or default value. In other words, if there is no entry for 
the requested attribute in the NamedNodeMap, then null is returned.

IE8 is being fixed to be conformant with what everyone else has implemented, I 
just thought I would pass this along to whomever is doing the DOM L3 Core 
Second Edition so that it might be recorded in that spec, an errata, or so that 
we can discuss.

Travis Leithead - OM Program Manager - Internet Explorer

Re: Proposed errata for DOM2 Range regarding insertNode()

[Ian Hickson]

Chaals, please see the end of this message.

On Wed, 28 May 2008, Jonas Sicking wrote:
> > 
> > It seems to me that everyone agrees that insertNode() was always 
> > intended to insert a node _into_ the range, and that the collapsed 
> > case was simply lost between the cracks when the DOM WG was writing 
> > the spec (much as was interaction with mutation events, for instance).
> 
> Everyone who? And based on what? I don't see anything in the spec that 
> suggests that. And as Olli pointed out there is clearly language in the 
> spec that indicates that the inserted node would be after the range in 
> the collapsed case.

Well, everyone except you and Olli apparently. :-)

Do you really think that it was intended for insertNode() to act 
differently when the range was collapsed than when the range wasn't 
collapsed, with respect to whether the inserted node ends up in the range 
or not?


> I guess I'm fine with making the change to the spec, but it would be a 
> change and not an errata.

I'm not sure what the distinction is.


> And if we're making changes anyway, I would requests that we make 
> NodeIterators behave like TreeWalkers as far as the returnvalue for the 
> NodeFilter goes. That is both more useful and easier to implement since 
> it allows more code reuse.

I recommend putting this forward as a separate errata. I only suggested 
this one because implementations seem to be differing on how to implement 
that part of the spec, and it seemed like it would be worth having a cycle 
that didn't require finding an editor to resolve the problem.

On the long term I do think we need to get Traversal Range rewritten with 
strict conformance requirements in mind.


On Thu, 29 May 2008, Olli Pettay wrote:
> 
> The current version of the spec handles dom mutations consistently 
> (whether using node.insertBefore/appendChild or range.insertNode) and 
> that is not something I'd like to lose.

This seems like a consistency that would hurt the authors, though. What's 
the use case for insertNode() inserting after the range?


> If that is changed, the insertNode part of the following wouldn't be
> true anymore (2.12):
> "Any mutation of the document tree which affect Ranges can be considered 
> to be a combination of basic deletion and insertion operations. In fact, 
> it can be convenient to think of those operations as being accomplished 
> using the deleteContents() and insertNode() Range methods and, in the 
> case of Text mutations, the splitText() and normalize() methods."

Indeed.


I do think that the spec intended the behaviour that I am proposing we 
clarify in errata, though I agree that it could be read otherwise. I 
honestly don't see any reason for the behaviour you advocate, it seems 
confusing, not useful, and not in line with the intent of the spec.

However, I'm not sure how to make further progress if you disagree to this 
change. It would be helpful if we could get a working group decision on 
this so that I could know whether the Acid3 test should be changed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: DOM based API

[Andrei Popescu]

On Fri, Jun 6, 2008 at 5:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Jun 6, 2008, at 7:55 AM, Mark Baker wrote:
>
>>
>> On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu <[EMAIL PROTECTED]> wrote:
>>>
>>> Hello,
>>>
>>> I am interested in working on a specification of a DOM API that allows
>>> Web pages to access the user's geolocation information (e.g. latitude
>>> and longitude).
>>
>> I'm very glad to see somebody mention using the DOM API for this kind
>> of information, right off the bat.  I'm a big believer in reuse, and
>> feel that this API is an obvious candidate for reusing the DOM, i.e.
>> providing a "Location" Javascript object that's also a DOM Document.
>
> I don't understand why you would want the "Location" object to be a DOM
> Document. (It needs a better name, by the way, so it doesn't conflict with
> the Location object that is window.location.) And I don't think that is what
> Andrei had in mind, as I understand it, he just wants an API that aligns
> well with the DOM, not necessarily one that makes non-markup information
> appear to be part of a Document.
>

That's right, what I meant is that I agree with the fact that this API
should align with existing standards, not that the Location object
itself should be a DOM Document. Anyway, I think we should start with
the use cases first? I'm planning to add a little more detail to that
section of the draft early next week and any feedback on this topic
would be very welcome.

Thanks,
Andrei

Re: DOM based API

[Maciej Stachowiak]

On Jun 6, 2008, at 7:55 AM, Mark Baker wrote:



On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu <[EMAIL PROTECTED]>  
wrote:


Hello,

I am interested in working on a specification of a DOM API that  
allows

Web pages to access the user's geolocation information (e.g. latitude
and longitude).


I'm very glad to see somebody mention using the DOM API for this kind
of information, right off the bat.  I'm a big believer in reuse, and
feel that this API is an obvious candidate for reusing the DOM, i.e.
providing a "Location" Javascript object that's also a DOM Document.


I don't understand why you would want the "Location" object to be a  
DOM Document. (It needs a better name, by the way, so it doesn't  
conflict with the Location object that is window.location.) And I  
don't think that is what Andrei had in mind, as I understand it, he  
just wants an API that aligns well with the DOM, not necessarily one  
that makes non-markup information appear to be part of a Document.


I think presenting geolocation info as a Document would have the  
disadvantages of more memory use and less obvious access for authors.


What are the advantages?

Regards,
Maciej

Re: DOM based API

[Andrei Popescu]

Hi Mark,

On Fri, Jun 6, 2008 at 3:55 PM, Mark Baker <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>>
>> I am interested in working on a specification of a DOM API that allows
>> Web pages to access the user's geolocation information (e.g. latitude
>> and longitude).
>
> I'm very glad to see somebody mention using the DOM API for this kind
> of information, right off the bat.  I'm a big believer in reuse, and
> feel that this API is an obvious candidate for reusing the DOM, i.e.
> providing a "Location" Javascript object that's also a DOM Document.
>

Thanks, I completely agree :)

> I note that you're at Google though, and that the Gears API doesn't
> reuse the DOM;
>
> http://code.google.com/p/google-gears/wiki/GeolocationAPI
>
> So I'm wondering if I've misunderstood you, or if Google has had a
> change of heart, or if you're perhaps not on the Gears team?
>

I am actually part of the Gears team and one of our main goals is to
contribute our ideas to standardization working groups, such as
WebAPI. Aaron Boodman (one of the Gears team TLs) has a very good blog
post on this issue:

http://gearsblog.blogspot.com/2008/04/gears-and-standards.html

All the best,
Andrei

DOM based API

[Mark Baker]

On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I am interested in working on a specification of a DOM API that allows
> Web pages to access the user's geolocation information (e.g. latitude
> and longitude).

I'm very glad to see somebody mention using the DOM API for this kind
of information, right off the bat.  I'm a big believer in reuse, and
feel that this API is an obvious candidate for reusing the DOM, i.e.
providing a "Location" Javascript object that's also a DOM Document.

I note that you're at Google though, and that the Gears API doesn't
reuse the DOM;

http://code.google.com/p/google-gears/wiki/GeolocationAPI

So I'm wondering if I've misunderstood you, or if Google has had a
change of heart, or if you're perhaps not on the Gears team?

Cheers,

Mark.

Re: Geolocation ideas

[Doug Schepers]

Hi, Folks-

Charles McCathieNevile wrote (on 6/5/08 8:01 PM):


On Thu, 05 Jun 2008 22:09:30 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote:

Matt Womer set up a (temporary?) playground to submit geolocation API 
documents for discussion:

 http://dev.w3.org/geo/
and
 http://dev.w3.org/geo/api

All of Chaals' caveats above apply to the new repo, too, of course... 
as do any IPR issues you can think of.  And any documents can be sent 
to the public-geolocation email list as attachments, too, if that is 
more convenient.


Although there is a W3C policy on what kind of attachments are 
acceptable. In short, please use HTML if you have to do this. (Having 
versioned documents is far better than attachments IMHO)


True.

FYI, if anyone needs a CVS account for Geolocation, please contact Matt 
or me.  If you need one for WebApps, contact me.



Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

[XHR] Last Call comment on about dependencies

[Shane McCarron]

The XHTML 2 working group discussed the XHR draft at a recent 
teleconference, and I was asked to send in a brief comment. 

Basically, the XHTML 2 Working Group is concerned that the draft appears 
to have a dependency on HTML5.  On closer inspection, it is not clear 
whether this dependency is completely necessary.  Further, linking the 
spec to HTML5 will delay its deployment and incorporation into other 
languages that have a vested interest in portable scripting (e.g. XHTML 
1, XHTML 2, XForms).   Finally, it appears that the dependecy is 
slightly backwards, since the requirement is that HTML5's document 
"Window" object support the XMLHttpRequest interface.  Our request is 
that this dependency be removed (or that the connection be made 
informative instead of normative) so that all interested constituents 
can take advantage of this important interface as soon as possible.


--
Shane P. McCarron  Phone: +1 763 786-8160 x120
Managing DirectorFax: +1 763 786-8180
ApTest MinnesotaInet: [EMAIL PROTECTED]

Geolocation API

[Andrei Popescu]

Hello,

I am interested in working on a specification of a DOM API that allows
Web pages to access the user's geolocation information (e.g. latitude
and longitude). Accessing this information would naturally require the
user's consent.

At this moment I would like to collect use cases and requirements from
anyone interested in such an API. I have already checked in at
dev.w3.org a skeleton document and I intend to fill it in during the
next few days based on the feedback I receive to this email. Please
note that the skeleton I checked in already has a couple of ideas
about use cases and requirements. I would be very grateful if you
could take a look at http://dev.w3.org/geo/api/spec-source.html and
let me know what you think.

Many thanks,
Andrei

Re: Potential bugs identified in XHR LC Test Suite

[Anne van Kesteren]

On Fri, 06 Jun 2008 04:47:31 +0200, Sunava Dutta  
<[EMAIL PROTECTED]> wrote:
 Meanwhile, I'd like to re-iterate a point I had raised up awhile back.  
Are the tests going to be 'complete' /comprehensive at CR in relation to  
the spec? MSFT obviously wants this test suite to be official ensuring  
that third parties do not write individual test cases undermining the  
credibility of the suite and demonstrating increased/decreased  
compliance post CR (when it's much harder to make changes).


The test suite will be made complete (and "official") during the CR period  
as per W3C policy. (And is required to be complete before we can exit CR.)



--
Anne van Kesteren