OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bad News on IE6 XML Support



I can't believe that you're the guy Microsoft sends to this list to work
this stuff out.

My concern is that interop means nothing to Microsoft and that all the work
we've done in SOAP interop is merely setting the stage for another of these
"arguments" which include absurd statements like your D, below.

Please pass this message up through the hierarchy at your company -- we'd
like to work with professionals who understand that the purpose of XML is to
have interop between competing software. I was tempted to send private email
into Microsoft about this, but decided that it was best to do the work in
public. We have similar issues at UserLand, I can't control what every
UserLand person says on mail lists at all times, so I'm willing to give
Microsoft the benefit of the doubt, and assume that your flame bait is just
Josh mouthing off (which you do on almost every mail list I'm on) and that
at some level Microsoft, as a matter of corporate strategy, cares at least a
little about achieving the promise of XML, although I'm beginning to think
I'm Polyanna In Hell for thinking that.

Others may have valid concerns about other issues -- I'm focused on SOAP,
and I want to make sure we don't get to this ridiculous place where interop
means so little and degrades to this kind of immature schoolyard banter.
This stuff matters Josh, and anyone else at Microsoft who's tuned in.

Dave


----- Original Message -----
From: "Joshua Allen" <joshuaa@microsoft.com>
To: "Dave Winer" <dave@userland.com>; <xml-dev@lists.xml.org>
Sent: Saturday, September 08, 2001 11:24 PM
Subject: RE: Bad News on IE6 XML Support


>whole I feel that his criticism has been fair, and it certainly is in
this
>case.

Which case?

A. Allowing users to look at "broken" XML files in the browser without
   fatally failing, when those documents contain low-range ASCII
characters.
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
doing wrong?"

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.