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

Re: XHR LC comments

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 27 May 2008 15:35:53 +0200
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.ubtep3dp64w2qv@annevk-t60.oslo.opera.com>

On Tue, 27 May 2008 14:29:16 +0200, Julian Reschke <julian.reschke@gmx.de>  
> You're still avoiding the question whether the URL parameter can be an  
> IRI. I would assume it can't, in which case the spec should require it  
> to conform to RFC3986.

It can. I made the specification more clear on this.

> If it's known to be a URI, do we really need to refer to HTML5 for  
> same-origin detection?

When I first defined same origin HTML5 had not yet defined it. I think it  
makes sense to keep such definitions in a single place so that it is clear  
that code can be re-used. Also, we already reference HTML5 for the  
definition of origin and other things.

>>> This has two problems:
>>> - it makes "stored used" an octet sequence, not a string.
>>  What is the problem?
> Well, octet sequences usually are not stored in strings but in byte  
> arrays.

Yes, English is a flexible language :-)

> I think what the spec currently says is confusing, and likely to cause  
> damage in practice.

I'm not convinced.

>>> - it simply doesn't work in practice, for instance for Basic  
>>> Authentication
>>  You're not really helping finding the right solution here. This was  
>> added for basic authentication if I remember correctly as it does not  
>> specify any encoding.
> Sometimes there is no simple solution.
> Basic Authentication is not defined in terms of UTF-8, and, as far as I  
> know, is not using it in practice, so suggesting that in XHR is a bug.

 From what I recall at least Firefox does it that way in practice.  
Currently it does not give any indication what kind of character encoding  
needs to be used so we picked the most obvious one.

>>> The goal for examples should be to illustrate a specific feature, not  
>>> to promote a specific coding practice (at least not when doing the  
>>> latter affects the readability).
>>  I don't think it affects readability that much.
> It probably doesn't affect you (because you prefer that notation  
> anyway), but minimally it affects me. And if it affects me, it's likely  
> to affect others as well.

It's likely to affect the copy-and-paste authoring crowd as well, and  
since it's unclear which is bigger, but the latter would actually be  
harmful, I kept the specification as is.

Anne van Kesteren
Received on Tuesday, 27 May 2008 13:35:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC