On Tue, 08 May 2007 12:58:12 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
wrote:
Fixed.
It would be helpful if you could say what changes you have made, rather
than relying on reviewers to somehow figure this out for themselves. I
take it you did not use my suggestion, but I can live with the result.
I did take your suggestion. Not having Content-Type specified now gives
you responseXML as well. I assumed you would read the diffs you receive
through e-mail. From now on I'll try to be more elaborate.
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.
I don't think it matters what vendors have indicated they would like.
If there are technical reasons that necessitate citing unregistered
media types in the draft, I would like to hear them. At the moment I
cannot agree with keeping unregistered types in the draft. I could
agree with not treating certain XML media types as XML media type,
but this surprising fact needs to be noted in the document.
The reason is that the draft needs to be reasonably compatible with
existing content such that it can be implemented without breaking content.
That's not non-compliant.
Then I must have misread the document. Could you elaborate on how to
arrive at your conclusion, so I can make a suggestion for changes that
would prevent my misunderstanding? To give a better example, why is an
implementation prohibited to execute open() step #10 before step #1,
or where does the draft says it is allowed to do that?
The user agent conformance class clearly says as long as the algorithm
used produces the same result it doesn't matter how they do it.
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...
A NOT_SUPPORTED_ERR DOMException would certainly be appropriate.
Ok, this is now part of the open() algorithm.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
