Re: [XHR] LC comments from the XForms Working Group

Mark Birbeck wrote:
>> 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 think he was implying that not all comment sources carry equal weight with him 
as an editor... But either way, I stand by my SVG Tiny example, for what it's worth.

> I was saying that this goes against
> the way specs progress within the W3C, since anyone can comment

Anyone can comment, but not everyone is (or should be, perhaps) listened to.

Again, this is a general point.  I'm NOT saying that you should not be listened 
to in this particular instance.

>> 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>.
> 
> 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 think you got a different message there than I did. My takeaway was that 
specifications will always end up focusing on some particular audience.  That 
includes W3C specifications.  This audience may well not include web browsers, 
as things stand, so web browsers should not be considered obligated to implement 
W3C specifications.

All the same things apply with "web browsers" replaced by any other constituency.

Again, this does not imply that in this particular case some particular 
constituencies are not relevant.

> 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.

Given the difficulty I've seen recently with finding spec editors, I'm pretty 
sure you're entirely too optimistic here.  Keeping two documents like this in 
sync is in fact a big deal, a good bit of work, and not sexy, so hard to find 
someone to do.

> I don't see this as a legitimate reason for not taking a more flexible
> approach to the XHR object.

If the more flexible approach requires importing parts of the Window definition 
in HTML5, then it's absolutely a legitimate reason to not do it.  In that case 
we need a better flexible approach.

>> 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.

The dependency is currently on the following things:

1)  The exact way of getting the right Window for the given XMLHttpRequest.
2)  The exact way of getting the right Document for the given Window and
     XMLHttpRequest.

I agree that these need not require a strong dependency on Window if item 1 can 
be addressed in some other way.

>> 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.

Your suggestion is more or less like mine, except you're focusing on two 
specific "constraints such a definition must satisfy" while I suspect there may 
be more.  What's needed to take this approach is a good list of places where the 
current spec depends on Window and the exact dependence.

>>> 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.

Your claim was that if UAs "took the web into account" then those three people 
would be less famous.  It's not clear to me what the basis of that claim is, but 
if you were saying that things like XMLHttpRequest would never have existed, for 
example, then I was pointing out that this is likely not the case.

If you meant something else, then I would be interested in knowing what you meant.

> Remove the *unnecessary* restriction that an XHR object can only
> function in the context of a Window object.

This needs to be replaced with other restrictions on the context object, in that 
case.  Which I think is a perfectly reasonable thing to do, if it can be done 
carefully and without introducing too much complexity into the XHR spec.  For 
example, importing HTML5 bits wholesale would fail those criteria.

> My point is also philosophical, but I'm not sure how your are responding to it.

I think the situation is that while I agree with your suggestion (or at least 
agree that it seems to be worth further study), I don't agree that the reasons 
currently given for the suggestion are necessarily strong enough to go through 
with it if there are substantial costs in terms of spec maintenance burden to 
doing so.

-Boris

Received on Tuesday, 17 June 2008 03:24:24 UTC