- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Mon, 16 Jun 2008 13:43:46 +0100
- To: "Boris Zbarsky" <bzbarsky@mit.edu>
- Cc: "Anne van Kesteren" <annevk@opera.com>, public-webapps@w3.org, public-forms@w3.org
HI Boris, On Fri, Jun 13, 2008 at 6:44 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Mark Birbeck wrote: >> >> Since when have W3C specifications been written only for certain >> audiences? > > Uh... Are you serious? The SVG Tiny specs aren't written for certain > audiences, for example? Anne was implying that only comments received from certain audiences were relevant to the XHR draft. I was saying that this goes against the way specs progress within the W3C, since anyone can comment. Hopefully that's a little clearer, and more serious. >> The whole point of the process of review and 'last call' is >> to get comments from various interested parties. You are saying that >> you have already decided who the interested parties are. > > I think it's more a matter of not all interested parties necessarily being > created equal. If you haven't read it yet, I urge you to read > <http://dbaron.org/log/2006-08#e20060818a>. > > (Note that this is a general comment, not specific to this particular point > about Window.) Right. And whilst I agree with a lot of it, my warning at the end of the email was that we are now witnessing the same behaviour being displayed by those who quite rightly criticised the 'corporate monopolisation' of the W3C in the past. >> I don't really follow this. > > For one thing, XMLHttpRequest same-origin checking needs to work the same > exact way as all otehr same-origin checking in the UA, to avoid introducing > security bugs. HTML5 will define same-origin checking in HTML. It was > decided to reference this rather than duplicating a large chunk of that spec > and possibly having spec skew). That's really not a big deal. If people need some help with doing this, then I'm sure there are plenty of people who would volunteer some time. I don't see this as a legitimate reason for not taking a more flexible approach to the XHR object. > If we have a better proposal for how that goal (that the same definition of > "same origin" is used everywhere) can be accomplished, I agree that would be > nice. As above...I think most people would see this as trivial. But it's good news to hear that there is scope for the XHR draft to be changed to loosen up the requirement on Window. > Similar for the other things Window gives us now (base URI definition, etc). Like what? Window gives us Document which gives us the base URI, so the dependency is on Document, and not Window. What would be the other dependencies? > Perhaps we should define how these things work when we're in a Window and > make it clear that any use of XHR in any other context will mean it's the > other context's responsibility to define exactly how XHR behaves there, and > list all the constraints such a definition must satisfy. That seems very heavy-handed. Why not just indicate that anyone using XHR will need to provide a context, and that context needs to provide a base URI against which relative URI references can be calculated, and security considerations can be resolved. That doesn't stop authors saying 'and by the way, in the case of Window and Document, those constraints are met as defined in HTML 5'. Pretty straightforward. >> If browser vendors (of all shades, not just Microsoft) had >> 'taken the web into account' in the past, then Thomas Fuchs, Sam >> Stephenson and John Resig would not be as celebrated as they are. So >> forgive me if I don't trumpet the arrival of the cavalry in the form >> of limited specifications created by some of the browser vendors. > > I'm not sure I follow this. "Taking the web into account" does not preclude > new functionality; it just limits what the spec can do with > already-implemented functionality. My turn to not follow what you are saying...sorry. >> And before you reply about 'ivory towers', and 'designing for the real >> web', etc., the XForms WG is only asking for one or two lines to be >> added to the spec. > > See above about ensuring certain things about security policy; it wasn't > clear to me that your addition addresses that issue sufficiently. The XForms WG doesn't have an addition, it has a removal: Remove the *unnecessary* restriction that an XHR object can only function in the context of a Window object. >> The frightening thing about your attitude here is that it is >> completely counter to the prevailing trend that embraces code-sharing, >> open source, anti-patents, open standards, and so on. > > Just as a note, open source doesn't mean arbitrary changes or features are > accepted. Neither should open standards, though it often seems like they do > work that way. Since nothing I've said looks like I'm arguing for 'arbitrary changes or features' to be simply accepted on the basis of 'openness', I'm not following who your 'note' is aimed at. I don't know if you intentionally took my point in another direction, but just so that the original point doesn't get lost I'll restate it. Anne responded to the XForms Working Group request to remove the dependency on Window (and I see in a separate thread that the SVG WG is looking at the same issue), by saying 'we don't need that flexibility in HTML 5...so why don't you go and write your own spec'. My response was, 'why should we?' (Although of course, if we have to, we will.) Anne and others (myself included) benefit *enormously* from work done by producers of open source software, and open standards. Many people take pride in the fact that their work is used by others, perhaps in a new piece of software, or by one standard incorporating another, and so create their work in such a way that it can be re-used more broadly. So it's a wholly unhelpful (and worrying) attitude for Anne to take, to imply that the XHR spec won't be changed because he and his colleagues don't need it changing, and that anyone who wants it changing should simply 'produce their own'. (Obviously it's not clear whether Anne is presenting his own prejudices about software architecture, or those of the WebApps group, so we need to wait and see how deeply this problem runs.) > (That's not a comment on the particular suggestion here; just a general > philosophical point in response to your general claim.) My point is also philosophical, but I'm not sure how your are responding to it. Regards, Mark -- Mark Birbeck, webBackplane mark.birbeck@webBackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)
Received on Monday, 16 June 2008 12:44:23 UTC