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. Cheers, Sunava Here's a link to the specs that fail fyi. http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/011.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/012.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/013.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/016.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/024.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/026.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/027.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/030.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/031.htm http://tc.labs.opera.com/apis/XMLHttpRequest/responseText/002.htm http://tc.labs.opera.com/apis/XMLHttpRequest/responseText/003.htm http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/006.htm http://tc.labs.opera.com/apis/XMLHttpRequest/abort/008.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/003.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/005.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/006.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/007.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/008.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/010.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/007.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/003.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/010.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/011.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/013.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/014.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/015.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/016.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/020.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/021.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/001.htm http://tc.labs.opera.com/apis/XMLHttpRequest/complex/001.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles McCathieNevile Sent: Friday, February 08, 2008 12:03 PM To: Chris Wilson Cc: Sunava Dutta; [email protected]; 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 <[EMAIL PROTECTED]> 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. cheers Chaals > -----Original Message----- > From: Doug Schepers [mailto:[EMAIL PROTECTED] > Sent: Friday, February 08, 2008 1:54 AM > To: Maciej Stachowiak > Cc: Anne van Kesteren; Sunava Dutta; [email protected]; 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
