W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

RE: IE Team's Feedback on the XHR Draft

From: Sunava Dutta <sunavad@windows.microsoft.com>
Date: Fri, 8 Feb 2008 20:09:07 -0800
To: Charles McCathieNevile <chaals@opera.com>, Chris Wilson <Chris.Wilson@microsoft.com>
CC: "public-webapi@w3.org" <public-webapi@w3.org>, Gideon Cohn <gidco@windows.microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>, Marc Silbey <marcsil@windows.microsoft.com>, Ahmed Kamel <Ahmed.Kamel@microsoft.com>
Message-ID: <B3AE6274B5AA584AAADD090DD30E5A0D339EAC290F@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>
Thanks Charles.
I agree with your plan. The test cases should be completed during LC and ready for UA testing. This will allow for increasing interoperability by allowing all parties to reach a better resolution for deltas. As we all know, interoperability will allow web developers to build against browsers without much pain.

Important-> We agree, let’s move the spec to LC.-:)

Testing expeditiously will benefit all parties. Linking it to the specification will add more credibility, make understanding the correlation to the spec easier (testing is easier for us too) and eventually improve interop. Running a full-fledged test suite against our browsers to verify interop is a critical next step that should happen before CR. We’d appreciate it if the tests can be matched with the spec by linking the relevant test to the spec section if possible (may be tough) or linking them at the bottom. This is a detailed spec and it will help. We’ve run the test suites as promised in addition to giving feedback. I realize the tests may be incomplete and lots of reference files are not accessible to us. For interoperability, if a test does fail on all browsers (right now 32 fail on 4 major browsers using the incomplete existing suite. See bottom) I would say it would be useful to have a plan for a default given that this is an existing feature that’s been on the web for a decade? Otherwise it may become an academic exercise and create confusion. Either way, we recommend resolving these deltas to determine behavior and LC may be an appropriate time to do this. We appreciate the effort the authors have put in here creating the test suites and we'd also be more than glad to create a local copy of the test so we can know where IE fails. Would it be possible once the tests are relatively stable to package them (including reference files) and send us a copy?

Reemphasizing what Chris mentions, we do believe that detail is good as long as it's readable and easy to assimilate. I humbly suggest removing or in the minimum mentioning which parts are UA implementation details that are not necessarily binding, especially if those areas achieve the same end result to users. I have heard points in the contrary mentioning that the content is suitable for the audience but I do feel while plenty of web developers are very technical, the web developer community at large could benefit if the content is better delineated/factored. The existence of XHR developer guidelines on the web today does not mean having a section in this W3C spec for developers would be unnecessary. A W3C spec is universally acknowledged to be official, has process and authority and is therefore different from those tutorials. These are our thoughts and may be dismissed or addressed if deemed appropriate at LC.


Here's a link to the specs that fail fyi.

































-----Original Message-----
From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org] On Behalf Of Charles McCathieNevile
Sent: Friday, February 08, 2008 12:03 PM
To: Chris Wilson
Cc: Sunava Dutta; public-webapi@w3.org; Gideon Cohn; Zhenbin Xu; Marc Silbey; Ahmed Kamel
Subject: Re: IE Team's Feedback on the XHR Draft

On Fri, 08 Feb 2008 22:22:59 +0530, Chris Wilson
<Chris.Wilson@microsoft.com> wrote:

> I think there are a few misconceptions about Sunava's feedback.
> 1) In NO WAY do we want the specification to be less detailed.  MORE
> detailed, if anything.

Yeah, we cleared that up at the technical plenary in my mind.

> 2) In fact, on that note, we're interested to see the test suite be
> linked, normatively if necessary.

Yes. I think this is a valuable piece of feedback. Currently W3C process
doesn't require test suites until you're trying to get out of CR and I
think it would be better to have them earlier.

> 3) we are not intending to block last call, and we understand the
> Process.  Sunava had promised to send comments, and has done so.  We
> would still like to see these comments addressed in the specification,
> and not simply dismissed; whether that is prior to or post LC is not, I
> think, that important.

OK, thanks. I have no intention of simply having comments dismissed. I
have held the last call question open to allow for a sensible discussion.

What I am thinking now is that we should check whether there are
substantive comments that need to be addressed before LC (on my first
reading I don't think so), and continue pretty fast to last call. I would
like the group to start checking the test cases we have against the spec
and formally agreeing them to facilitate this linkage during last call. It
slows down the LC period, but it should make CR easier and reduce the
possibility of reverting from CR.

How do people feel about that as an approach?

Finally, on the question of what we agreed at the technical plenary, the
minutes do not reflect any resolution that we agreed we would make a spec
that is 100% compatible with IE - as Anne, Jonas and Maciej pointed out we
started out working from existing implementation including IE and trying
to make a spec that is as backwards compatible as possible, but that is
*a* goal not the driving requirement.

Naturally any specific requests for technical changes are welcome either
now or during Last Call, and will be considered on their merits. We had
hoped that any such comments would have come in already but one of the
reasons for going to last call when we have run out of comments at normal
working draft is to elicit any outstanding issues.

So I plan to give it a few days (I am only partly available over the next
few days, in India, Poland, Spain, Norway in the next week) and then I'll
propose a formal consensus call on a way forward - based on the above
thoughts and comments here over the next week.



> -----Original Message-----
> From: Doug Schepers [mailto:schepers@w3.org]
> Sent: Friday, February 08, 2008 1:54 AM
> To: Maciej Stachowiak
> Cc: Anne van Kesteren; Sunava Dutta; public-webapi@w3.org; Gideon Cohn;
> Zhenbin Xu; Chris Wilson; Marc Silbey; Ahmed Kamel
> Subject: Re: IE Team's Feedback on the XHR Draft
> Hi, Folks-
> To be clear, I'm not critiquing the spec itself, or advocating any
> specific action.  Rather, I'm trying to manage expectations and ensure
> that the various participants of this WG can work smoothly with one
> another.  I'm acting purely as a Process wonk here.
> Sunava, as you see, there is considerable, and reasonable, incentive to
> make the XHR spec as detailed as possible, even where it may not match
> the IE implementation precisely.  Maciej's request for more specific
> details on potential conflicts (in implementations or content) is
> appropriate, I think.
> I don't know if you are familiar with the W3C Recommendation Track [1],
> so briefly, you should know that LC (Last Call) is not the end of the
> process.  It simply indicates that the specification is believed to have
> satisfied its technical requirements; it's not considered stable enough
> for implementation, and in practice, this is when most comments are made.
> Thus, I see little harm in advancing to LC, since you will still have an
> opportunity to submit additional technical comments.
> [1] http://www.w3.org/2005/10/Process-20051014/tr

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

Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Saturday, 9 February 2008 04:09:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:58 UTC