[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bad News on IE6 XML Support
- From: Joshua Allen <email@example.com>
- To: Dave Winer <firstname.lastname@example.org>, email@example.com
- Date: Sat, 08 Sep 2001 23:24:39 -0700
>whole I feel that his criticism has been fair, and it certainly is in
A. Allowing users to look at "broken" XML files in the browser without
fatally failing, when those documents contain low-range ASCII
B. Failing when users try to view XML in the browser, when there are
characters above 0x10000.
C. Not recognizing a mime type which does not exist, and recognizing
another that also does not exist, but is used in most browsers.
D. Being "mean and evil"
These are the 4 criticisms I saw brought up. I think A and B can be
considered standards conformance bugs, and are not severe enough
magnitude to be proof of D. Since your company sells software that
produces and consumes XML, you are obviously basing your assessment of
the validity of the criticism on real-world experience. This is the
most valuable kind of feedback, so I would be interested in knowing what
your experience regarding issues A and B has been.
For example, I know that users can store low-range ASCII in Radio
Userland and Manila let me use such characters, and even propagates
those characters to the RSS file that says XML 1.0 in the declaration.
So it is quite possible that your users have had the unfortunate
experience of having IE allow them to view XML created by Userland
software. Do a significant number of your users complain that "IE does
not seem to crash properly on my RSS produced by Radio -- what am I
And regarding issue "B", I would think this would be an even more vexing
problems for those users who use characters above the 0x10000 range. It
is indeed a bug for IE to crash on perfectly valid XML that has
characters in this range. It would be helpful to know if many of your
users, in your experience, are being nailed by this bug. I don't use
Manila or Radio to publish characters in that range, since I gave up
after failing to figure out how to make these products accept valid
Unicode Chinese characters (which are not affected by issue B anyway).
So I was not aware of any support in those products for characters in
the > 0x10000 range, so I would have to defer to your expertise to
assess the full magnitude of this bug.