On Tue, 08 May 2007 11:59:42 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
wrote:
* Anne van Kesteren wrote:
* For compatibility reasons the character encoding detection
for decoding responseText has been changed.
I find some of these changes somewhat odd. For example, if there is no
Content-Type header, the encoding is detected as if the resource was a
application/xml resource, but .responseXML is populated as if the re-
source was non-XML (it's set to null). It would be more consistent and
easier to understand if it just said, if there's no Content-Type header,
assume application/xml.
Fixed.
* text/xsl has been added as a MIME type that causes
responseXML to return a Document object (if the resource
can indeed be parsed according to the XML specfications.)
Again, for compatibility reasons.
There is no need for the draft to encourage use of unregistered media
types, and there is very little need for the draft to apply non-XML
treatment to media types like application/smil which are defined for
use with XML documents. I believe it is entirely sufficient and more
appropriate to state, for example, "If the internet media type in the
Content-Type header indicates the entity body is an XML document, ...".
Vendors have indicated they would like to have defined what that would
mean, which is what the draft now tries to say. This indeed excludes (now
obsolete?) MIME types such as application/smil but I don't think that will
cause a problem in practice. If it does, I suppose we should get
implementation feedback during CR.
* Most members are now defined as algorithms which makes the
result of a method more clear (hopefully) and also helped
me fixing several issues.
Why is it necessary to make implementations non-compliant if they e.g.
check for same origin restrictions before checking whether some pass-
word uses proper syntax?
That's not non-compliant.
It seems by the way the draft does not say
what happens if the implementation does not support a particular scheme
(say you attempt to open a 'mailto' URL, or there is no TLS support.)
What would you suggest? NOT_SUPPORTED_ERR comes to mind but I'm not sure
if that's appropriate...
I don't understand why the send() implementation must dispatch a
readystatechange event *after* it raised an exception. The only way to
tell the difference would be an exception handler that checks that the
event listener had not been invokved. The "(Don't abort these steps.)"
note suggests this is deliberate, but if this is truly necessary, the
draft needs to say why.
Fixed.
Thanks for reviewing!
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
