Anne van Kesteren wrote:
- If the URL parameter can be a IRI, then somewhere later on we need
to state that it needs to be transformed to a URI before it's put on
the wire.
Added a transformation step as per 3.1 and also required throwing a
SYNTAX_ERR in case of failure (ToASCII operation
On Tue, 27 May 2008 15:44:21 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
On Tue, 27 May 2008 14:29:16 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
You're still avoiding the question whether the URL parameter can be an
IRI. I would assume it can't, in which
Julian Reschke wrote:
...
If stored method is GET act as if the data argument is null.
Another case of HTTP/1.1 being profiled. Don't do it.
...
For the record, the HTTPbis WG discussed the issue of GET/HEAD with
request bodies a few months ago, and the resolution was that in general
they
Bjoern Hoehrmann wrote:
* Julian Reschke wrote:
- If the URL parameter can be a IRI, then somewhere later on we need to
state that it needs to be transformed to a URI before it's put on the wire.
Actually that is for the HTTP specification to define, which right now
does so implicitly by
On Thu, 15 May 2008 20:57:44 +0200, Laurens Holst
[EMAIL PROTECTED] wrote:
When invoking request.setRequestHeader('Accept', ''):
- Firefox 3b5 removes the Accept header
- Internet Explorer 8 (in IE7 mode) sends Accept: */*
- Safari 3.1.1 sends Accept:
- Opera 9.24 sends Accept: text/html,
Julian Reschke wrote:
...
Currently there is no conversion, and what is specified clearly can
cause implementations to create broken requests, where the code worked
before.
...
...even without looking for it, I came across this one:
Bjoern Hoehrmann wrote:
* Boris Zbarsky wrote:
Bjoern Hoehrmann wrote:
Being able to send wf-but-ns-illformed documents would not make much
sense if you couldn't also read them back in
Which you can, with a non-NS-aware XML parser.
My point was that the XHR draft currently requires using a
On Mon, 19 May 2008 05:07:52 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
and you can rather easily check for ns-wf during serialization if you
implement
the serialization yourself
Perhaps. This is less clear to me. In particular, it's not that clear
to me that its trivial to decide
* Boris Zbarsky wrote:
On the server side?
No, I was simply trying to say XHR should not generate output it cannot
parse itself. Either it generates and parses a document, or it neither
generates nor parses a document. If there was a parameter to set, like
LSParser.domConfig.namespaces, to
Simon Pieters wrote:
FWIW, this is defined for getting innerHTML in XML:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dynamic.html#innerhtml1
That's more like what I was looking for, yes. I would be happy if XHR adopted
that approach.
-Boris
Inline...
-Original Message-
From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 17, 2008 5:45 AM
To: Julian Reschke
Cc: Maciej Stachowiak; Sunava Dutta; Web API WG (public)
Subject: Re: XHR LC comments
On Sat, 17 May 2008 14:23:24 +0200, Julian Reschke [EMAIL
Sunava Dutta wrote:
I think you mean compatible with browsers who enable
the technologies when you mean compatible with the web?
Compatible with the web means that when a UA implements the specification as
written it will encounter either no reports of pages broken due to that
Sunava Dutta wrote:
Inline...
-Original Message-
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 3:14 PM
To: Sunava Dutta
Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG
(public); IE8 Core AJAX SWAT Team
Subject: Re: XHR LC comments
Inline...
-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 17, 2008 2:04 AM
To: Julian Reschke
Cc: Sunava Dutta; Anne van Kesteren; Web API WG (public)
Subject: Re: XHR LC comments
On May 17, 2008, at 1:03 AM, Julian Reschke wrote
Julian Reschke wrote:
For this one I used Dom L1 methods to create this document:
foox:y//foo
which isn't XMLNS-wellformed.
I'm not sure I see the problem here, to be honest... Using the
non-namespace-aware DOM methods one can indeed create documents that require a
non-namespace-aware
Julian Reschke wrote:
Since the UA has no idea what sort of XML parser is being used on the
server side, I'm not sure it makes sense to bail on attempts to
serialize such documents. In particular, if the document _is_ parsed
with a non-namespace-aware XML parser, there is no problem.
Boris Zbarsky wrote:
Julian Reschke wrote:
Since the UA has no idea what sort of XML parser is being used on the
server side, I'm not sure it makes sense to bail on attempts to
serialize such documents. In particular, if the document _is_ parsed
with a non-namespace-aware XML parser, there
Bjoern Hoehrmann wrote:
Being able to send wf-but-ns-illformed documents would not make much
sense if you couldn't also read them back in
Which you can, with a non-NS-aware XML parser.
and the odds that some
wf-but-ns-illformed has been created deliberately for use with XHR
as opposed to
* Boris Zbarsky wrote:
Bjoern Hoehrmann wrote:
Being able to send wf-but-ns-illformed documents would not make much
sense if you couldn't also read them back in
Which you can, with a non-NS-aware XML parser.
My point was that the XHR draft currently requires using a namespace-
aware one, so
On May 17, 2008, at 1:03 AM, Julian Reschke wrote:
Sunava Dutta wrote:
...
At this point, I'm not sure why we're bothering with XHR1 at all.
It is
*not* what the current implementations do anyway.
[Sunava Dutta] I'm sorry, this statement is concerning and I'd like
to understand it
Anne van Kesteren wrote:
On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
But what IMHO happens all over again is that strange choices in the
design are defended with the statement this is what the vendors do,
or want to do, and when we check it, that turns out to
On Sat, 17 May 2008 14:23:24 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
But what IMHO happens all over again is that strange choices in the
design are defended with the statement this
Julian Reschke wrote:
...
Data loss is not a safe choice, it's a bad choice.
Do you have any evidence of deployed code that would break if this would
throw?
...
I just tried with FF3 and IE7.
Using a non-ns-wellformed document:
- FF3: happily sends it
- IE7: couldn't figure out how to
Julian Reschke wrote:
Boris Zbarsky wrote:
Julian Reschke wrote:
Using a non-ns-wellformed document:
- FF3: happily sends it
Out of curiosity, what did this document look like? What got sent?
I removed the document element and added a comment node, so it looked like:
!-- foo --
Ian Hickson wrote:
...in which case I'd say that (a) the references aren't normative after
all, and (b) the spec itself can't be normative as it is written.
I don't mind calling the references informative if that's what it takes.
I'm not sure what practical difference it would make.
You
Julian Reschke wrote:
b) Algorithms: the spec uses a method to describe algorithms that IMHO
is extremely hard to read (see for instance send() method). This maybe
good for implementors, but seems to be bad for everybody else.
Minimally, the lists should be structured for better readability.
Anne van Kesteren wrote:
Since this is the second Last Call and credentials are already following
each other (and the same for other similar steps) I've decided not to
change this.
Unfortunately.
c) Structure: It would be nice if Section 4 had more structure.
Rightnow it's ugly to navigate
Ian Hickson wrote:
...
Incidentally, I think I would recommend removing the blacklist from AC,
since AC has a whitelist. Having both seems pointless.
...
You mean disallowing all headers except a known list??? Nope.
Again, that would mean profiling HTTP, and make it impossible to deploy
Ian Hickson wrote:
On Wed, 14 May 2008, Julian Reschke wrote:
The problem is that concepts such origin and determining the
encoding of a text/html stream are not defined anywhere else. It's not
really clear to me what to do about that.
In some cases, it may be possible to copy the current
On Thu, 15 May 2008, Julian Reschke wrote:
I don't have an opinion on the exact issue here, but as a general rule
I recommend against making decisions based on the political status
(rather than technical status) of working groups and specs. Otherwise
we just end [up invoking
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin (for instance) is pretty well
understood by browser vendors, and HTML5 is getting progressively closer
to defining it. XHR1 doesn't
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin (for instance) is pretty well
understood by browser vendors, and HTML5 is getting progressively closer
to defining it. XHR1 doesn't need it to be
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin (for instance) is pretty well
understood by browser vendors, and HTML5 is getting
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin (for instance) is pretty well
understood by browser vendors, and HTML5
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin (for instance)
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin (for
Ian Hickson wrote:
...
What's wrong with referencing HTML5? Why can't the spec be more ready than
its normative references? We're only really referencing the concept, the
details aren't particularly critical to XHR.
...
Because, by definition, normative references are part of the
Laurens Holst wrote:
Julian Reschke schreef:
Sorry, was reading one thing, but thinking about something else.
Thinking of it, could you please add a clarification that setting to
an empty string is legal, and MUST NOT be ignored? I recall that
Microsoft's original XHR (ActiveX)
Laurens Holst wrote:
Julian Reschke schreef:
Sorry, was reading one thing, but thinking about something else.
Thinking of it, could you please add a clarification that setting to
an empty string is legal, and MUST NOT be ignored? I recall that
Microsoft's original XHR (ActiveX)
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
...
What's wrong with referencing HTML5? Why can't the spec be more ready than
its normative references? We're only really referencing the concept, the
details aren't particularly critical to XHR.
...
Because, by
On Thu, 15 May 2008, Julian Reschke wrote:
But we don't have to limit ourselves to that definition. We could just
as easily say that XHR1's functionality is as defined in XHR1, and
that it uses terms and features that are currently underdefined. It
wouldn't, in
...in which case
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Thursday, May 15, 2008 1:35 PM
To: Julian Reschke
Cc: Anne van Kesteren; public-webapi@w3.org
Subject: Re: XHR LC comments
On Thu, 15 May 2008, Julian Reschke wrote:
But we don't have to limit ourselves to that definition. We
On May 15, 2008, at 1:24 PM, Julian Reschke wrote:
practice, take anything away from the ability to get interoperable
implemenations of the feature described in XHR1.
Really?
What if Apple implements the thing as defined by HTML5-as-of-2008,
and Microsoft as defined in
On Thu, 15 May 2008, Travis Leithead wrote:
The point is that Apple and Microsoft are both going to implement the
thing as required by the Web in 2000, not as defined in HTML5. HTML5 is
describing existing practice on these matters, not defining new
material.
Well, a _few_ bits of new
On Sun, 04 May 2008 11:47:13 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Review of http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/.
General points:
a) I'm confused about the approach to this document. On the one hand,
we're being told that it can't define anything not already in
Core AJAX SWAT Team
Subject: Re: XHR LC comments
Sunava,
it would be helpful if you'd use a mail client that can properly quote
:-) In your mail your text appears as if it was indirectly quoted by
myself... I have reformatted your reply so it becomes clear again who
said what.
Sunava Dutta wrote
Julian Reschke wrote:
a) I'm confused about the approach to this document. On the one hand,
we're being told that it can't define anything not already in use (and
that new stuff belongs into XHR2), on the other hand it relies on HTML5,
which is a moving target. It's good that this stuff is being
47 matches
Mail list logo
