Re: Posting with XHR and ISO-8859-15

Conrad Lender wrote:
Thomas 'PointedEars' Lahn wrote:
Conrad Lender wrote:
That you blindly fell for it does not bode well for the quality of
your other code.
Don't judge what you've never seen.
I had not judged anything, but given what you have written below, it
would seem my worst expectations were fully met.

I'm going to snip the rest of your rant and concentrate on the
interesting bits. This kind of bickering and name-calling may be fun for
you, but I'm more interested in a productive dicussion. If you want to
continue this on a personal level, feel free to email me.

You started it by parroting nonsense.

That's just the way the web develops; [..] new features are
implemented and used, and are later made into a full standard.
Yes, *later*. When it is a Recommendation (REC). *Then* it has
fulfilled the exit criteria (among them, at least two interoperable
implementations for every feature) and has got the endorsement of the
Director and the W3C membership that makes it deservedly be called a
standard; not before.

There's no such thing for the XMLHttpRequest object;

Exactly my point, which you keep on missing.

as of now, there is only the Working Draft, which is explicitly endorsed
by at least Microsoft, Mozilla, and Opera.

One wonders what makes you think that a simple link to the draft that is
explicitly marked with the word(s) "working draft" could be understood as an
endorsement. In any case, it doesn't mean anything, especially not for MDC
(which is a public Wiki). For it is *known* that current implementations of
that interface are _not_ interoperable.

In fact, the MSDN site links to this very document for reference:
| This optional varBody parameter may be a String, array of
unsigned | bytes, or an XML Document Object Model (DOM) object. For
additional | information, see send Method (IXMLHTTPRequest).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So, in fact, they do *not* say how it is encoded by default.

Not on that page, that's what I said.

It doesn't say in the documentation for IXMLHTTPRequest::send() either.

Even the link (marked here) is wrong, it points to
IXMLHTTPRequest::open(). (I doubt you had missed that, had you
followed it in the first place.)

Don't complain to me about a typo on the MSDN site.

I am pointing out your lack of research, and misinterpretation
of what little research you did (if any), instead.

http://msdn.microsoft.com/en-us/library/ms763706(VS.85).aspx

Lo and behold:

Hardly.

| If the input type is a BSTR, the response is always encoded as UTF-8.
| The caller must set a Content-Type header with the appropriate content
| type and include a charset parameter.

So, what is a BSTR in *JScript*, fool?

Micro$~1 has a tendency to claim standards compliance (sometimes even
falsely) when it fits them. [...] The only authoritative source *for a
particular implementation* is the implementation itself (the source
code or at least a test case), maybe backed up by its documentation;
certainly not any Working Draft being referred to:

For crying out loud, Microsoft *invented* the thing.

I know. That does not mean anything for the importance of the Working
Draft, though.

The W3C document came later [...]

You don't say. And what you seem to miss is that the W3C *Working Draft*
came after other vendors tried to implement that interface, and did not do
so in an interoperable way. (However, you can hardly blame them, given M$
attached the feature to the `ActiveXObject' constructor for many years, and
that it was Closed Source.)

Unless you have anything constructive to add, this is EOD for me.

I have told you what the situation really is, contrasting the fairytales
you have been told and that you preferred to believe. That the situation as
it is does not satisfy you (or me) does not mean that my explanation was
incorrect or not constructive at all. Insofar an apology on your part would
be in order.


PointedEars
.

Relevant Pages

  • Re: Comparing lists
    ... The list implementations has been tweaked to produce better performance appending and popping. ... I find the Python docs surprisingly good for even commercial documentation. ... Once you decide that isn't good enough, the burden on creating the documentation is getting substantial, especially given that you've already spent the effort to write the code and tests for it. ... However, "experimenting" puts the cost on the person who derives the benefit, and is thus likely to not be done in a slipshod way. ...
    (comp.lang.python)
  • Re: Documentation strings for class-slots
    ... strings for individual slots specified in a defclass form, ... implementations might still provide debugging tools and/or ... Even MOP doesn't specify anything to retrieve the slot documentation: ...
    (comp.lang.lisp)
  • Re: /sub/dir
    ... directory and namestring formats documented somewhere? ... The second form should be highly portable, at least to lisp ... implementations running on machines with hierarchical file systems. ... would have to be documented in the implementation documentation. ...
    (comp.lang.lisp)
  • Re: random number
    ... implementations provide a new seed each time (probably ... You have to read the specific compiler's documentation ... the proper call is not portable since the ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)