Maciej Stachowiak wrote:
On May 14, 2007, at 9:26 AM, Bjoern Hoehrmann wrote:
* Anne van Kesteren wrote:
It was added for compatibility with WebKit. I don't really feel strongly
about it, ...
Excellent, I then look forward to a proposal that Jonas and I do not
regard as inappropriate.
I do
On Mon, 14 May 2007, Maciej Stachowiak wrote:
>
> The question we should be examining is whether [text/xsl] is actually
> used in practice. If it is, then the right course of action is to get it
> registered with the IETF (and presumably marked deprecated). If it
> isn't, then we can safely req
* Maciej Stachowiak wrote:
>I don't personally feel strongly about this particular issue (I don't
>think it is common for sites to send text/xsl as a MIME type on the
>wire), but since when is the fact that someone "regard[s] [it] as
>inappropriate" a valid reason to change something? Should
On 5/14/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
Defining particular behavior when a type is seen is not the same as
standardizing it, in my opinion.
Disagree, since MIME types are used to route messages to code with
particular behaviors. However, I personally don't feel too strongly
On May 14, 2007, at 10:52 AM, Robert Sayre wrote:
On 5/14/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
Personally I don't think lack of registration is a particularly
strong reason not to define handling for a particular MIME type.
At the very least, the W3C/IETF liasons should discuss
On 5/14/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
Personally I don't think lack of registration is a particularly
strong reason not to define handling for a particular MIME type.
At the very least, the W3C/IETF liasons should discuss this. It is
exceedingly bad manners to squat a on pa
On May 14, 2007, at 9:26 AM, Bjoern Hoehrmann wrote:
* Anne van Kesteren wrote:
It was added for compatibility with WebKit. I don't really feel
strongly
about it, ...
Excellent, I then look forward to a proposal that Jonas and I do not
regard as inappropriate.
I don't personally feel s
* Anne van Kesteren wrote:
>It was added for compatibility with WebKit. I don't really feel strongly
>about it, ...
Excellent, I then look forward to a proposal that Jonas and I do not
regard as inappropriate.
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str
On Thu, 10 May 2007 17:21:30 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
wrote:
* Anne van Kesteren wrote:
If one UA treats Content-Type:text/foobar as XML and another UA does not
and a site starts relying on text/foobar being treated as XML we have a
problem.
We have very many problems of
On Wed, 09 May 2007 00:49:56 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Anne: was there a reason 'text/xsl' was included other than "IE does
it"? Or is it known to actually break sites?
A Contributor from WebKit implementing XMLHttpRequest requested it to be
included for compatibility
Boris Zbarsky wrote:
Bjoern Hoehrmann wrote:
http://www.bjoernsworld.de/temp/axmlb-test.html alerts FAIL in browsers
treating axmlb/test as XML type, which my versions of Firefox do; so it
does seeem true to me. `text/rdf` btw, does not seem to be supported as
XML type for XHR purposes in Fire
Bjoern Hoehrmann wrote:
http://www.bjoernsworld.de/temp/axmlb-test.html alerts FAIL in browsers
treating axmlb/test as XML type, which my versions of Firefox do; so it
does seeem true to me. `text/rdf` btw, does not seem to be supported as
XML type for XHR purposes in Firefox.
That's correct.
* Jonas Sicking wrote:
>Alexey Proskuryakov wrote:
>> 2) Firefox 2 recognizes anything with "xml" in it (e.g. "fooxml/bar").
>
>I really doubt that is the case. Could you provide a testcase showing
>this to be true?
http://www.bjoernsworld.de/temp/axmlb-test.html alerts FAIL in browsers
treating
Alexey Proskuryakov wrote:
2) Firefox 2 recognizes anything with "xml" in it (e.g. "fooxml/bar").
I really doubt that is the case. Could you provide a testcase showing
this to be true?
/ Jonas
Hi!
* Bjoern Hoehrmann <[EMAIL PROTECTED]> [Thu, 10 May 2007 17:21:30
+0200]:
I was unable, by the way, to get any browser but Opera to recognize
the
type text/xsl as XML MIME type; Firefox from 1.5 to Minefield does not
seem to recognize it, and neither do IE6 and IE7 (on different
vers
On Wednesday, May 9, 2007, 7:05:30 AM, Björn wrote:
BH> * Maciej Stachowiak wrote:
>>I'm also not sure of the benefit of letting the UA treat arbitrary
>>other types as XML besides those listed. Modern XML MIME types should
>>all be following the +xml convention.
BH> It is false to assert m
On Thursday, May 10, 2007, 2:07:48 PM, Anne wrote:
AvK> On Wed, 09 May 2007 07:18:32 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
AvK> wrote:
>>> The reason is that the draft needs to be reasonably compatible with
>>> existing content such that it can be implemented without breaking
>>> content.
* Anne van Kesteren wrote:
>If one UA treats Content-Type:text/foobar as XML and another UA does not
>and a site starts relying on text/foobar being treated as XML we have a
>problem.
We have very many problems of this nature right now. If I use XML 1.1 my
site won't work in Firefox, if I use
On Wed, 09 May 2007 07:18:32 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
wrote:
The reason is that the draft needs to be reasonably compatible with
existing content such that it can be implemented without breaking
content.
If you think my suggestion would break existing content, it would b
* Anne van Kesteren wrote:
>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.
Thanks.
>The reason is that the draft needs to be reasonabl
* Maciej Stachowiak wrote:
>I'm also not sure of the benefit of letting the UA treat arbitrary
>other types as XML besides those listed. Modern XML MIME types should
>all be following the +xml convention. And clearly for
>interoperability we want it to be the case that the UA MUST NOT treat
Maciej Stachowiak wrote:
If we are making the list absolute, I feel weird about including
things like 'text/xsl' and 'text/rdf' as neither of them are real
mimetypes. Is there really a lot that would break if 'text/xsl' was
not included?
No clue. I don't think it's bad to make requirements f
On May 8, 2007, at 3:29 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
On May 8, 2007, at 1:25 PM, Jonas Sicking wrote:
[1] not sure if it should be a MUST or SHOULD requirement.
It should be a MUST because:
- We want test cases to cover it.
- There's no sensible reason to let a UA to n
Maciej Stachowiak wrote:
On May 8, 2007, at 1:25 PM, Jonas Sicking wrote:
Anne van Kesteren wrote:
* 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 com
On May 8, 2007, at 1:25 PM, Jonas Sicking wrote:
Anne van Kesteren wrote:
* 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.
Ther
Anne van Kesteren wrote:
* 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 unregi
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
* Anne van Kesteren wrote:
>> 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
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
Cont
* 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
Hi,
The latest editor's draft of the XMLHttpRequest can be found here:
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8
In addition there's also a disposition of comments document for the first
Last Call:
http://dev
31 matches
Mail list logo
