[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bad News on IE6 XML Support
- From: Michael Rys <firstname.lastname@example.org>
- To: Elliotte Rusty Harold <email@example.com>, firstname.lastname@example.org
- Date: Fri, 07 Sep 2001 17:33:14 -0700
> From: Elliotte Rusty Harold [mailto:email@example.com]
> Sent: Friday, September 07, 2001 4:21 PM
> To: firstname.lastname@example.org
> Subject: RE: Bad News on IE6 XML Support
> At 2:41 PM -0700 9/7/01, Joshua Allen wrote:
> >> http://www.w3.org/1999/XSL/Transform
> >> namespace. This is about two years too late, but
<snip topic="complaints about product decisions that could have been
handled differently but have not really affected the world as badly as
some people want to make it believe"/>
> > At least IE has been capable
> >of using the correct namespace with fully-supported products and
> >standards compliance for quite awhile.
> And yet you persisted in shipping non-compliant versions with
> IE. You proved that you could do better, and repeatedly
> failed to do so. This is not incompetence. This is deliberate choice.
Huh? IE picked up MSXML 3.0 that is fully compliant as soon as it was
available for their release (5.5 was too early). If you cared about it,
you could even retrofit your IE 5 and 5.5 with MSXML 2.6 and 3.0.
Eliotte, large software companies have very strict release cycles and
dates and dependency management. Plans are often made way in advance. So
yes, 5.0 and 5.5 shipped with a Working Draft version due to such
dependencies not being lined up between the W3C recommendation, IE and
MSXML. I can assure you that we did that all to attain world dominance
(or was it just because other priorities and dependencies were more
important in the more general picture?).
Microsoft's XML team probably waited a bit too long with following up
with proper XSLT support and there are several threads on xml-dev where
Microsoft people have taken the blame and apologized. Rehashing and
beating the dead horse over and over again will not fix this.
> > What other product can claim
> >that? This article is totally missing the point that the support for
> >the recommendation namespace *has* been available well before IE6
> However, since it's not installed by default it's irrelevant.
> We cannot use it or rely on it. What you actually did ship
> with IE 5.0 and 5.5 was a non-compliant version. Hiding a
> compliant version deep in your web site for those few experts
> who knew where to look (and how to install it) in no way
> absolves you from the sin of shipping millions of
> non-compliant versions.
<snip topic="CSS stuff that I do not know about"/>
> >There is no XML Parser "built-in"; IE6 uses MSXML 3.0, which ought to
> >be a paragon of standards-conformance (including rejecting illegal
> >characters). If you have specific bug reports with the conformance
> >MSXML, please let us know. We have seen a few conformance bugs that
> >believe have been fixed (even in IE6, the conformance bug fixes have
> >been integrated into MSXML3 as well as being added to MSXML4, so IE6
> >ships with fixes for some conformance bugs that Antenna House
> >and so on). Honestly, any objective data that we are seeing in
> >Microsoft makes us think that we have done a pretty good job of
> >a good example for conformance. I am someone feels it is "thoroughly
> >broken", but that doesn't give us much to go on.
> Microsoft already knows about this and made the choice for
> the reasons I described. Here's a malformed document:
> Internet Explorer 6.0 accepts it (and similar documents) and
> according to Microsoft's own Aung Aung
> (email@example.com) that choice was quite
> deliberately made: "Yes, IE is using msxml3.dll but that
> particular character checing was not fixed in IE for backward
> competibility reason. So, if you write a simple jscript to
> parser the xml it will be fine, but in IE it will give error."
Eliotte, please let me repeat what Joshua and Aung wanted to say on this
topic (and actually did say for those that read carefully):
MSXML 3.0 as it is used in IE 6.0 is running in a backwards
compatibility mode that replicates the previous errors so that client
applications that upgrade to 6.0 will not fail. If you use the MSXML 3.0
component directly in your programming and not on the client via IE 6.0,
you are getting 100% compliance (including an error on the document
Please understand again, that providing the possibility to be
backwards-compatible even with errors is one of the features that
differentiates a program that will be commercially or otherwise
successful from one that is not in the context of c/s and multi-tier
components. If you look closely at database systems such as Oracle or
SQL Server, you will see that you can specify compatibility levels that
sometimes provide buggy behaviour (e.g., the infamous ''=NULL bug/design
Since IE 6.0 needs to provide support for existing web sites/data, it
was clear that it would need to make use of this (note that this
approach - accept liberally, produce strict - is one of the reasons why
the web got this mass appeal). Should we have not made the bug in the
first place? Yes. But bugs get through and become "unwanted features",
especially if you have more than 10 customers. Have we fixed the bug in
MSXML 3.0? Yes. So people can start to transition to the bug less
> However, it was not in the spec when it was released. What
> was in that spec was text/xml and application/xml. Since that
> time application/xml+xslt has been added. I can understand
> why you made this mistake in IE 5.0. I can't understand why
> you chose to perpetuate this in IE 5.5 and IE 6.0.
See the previous paragraph.
> It's probably worse for me than you. I receive more than
> weekly emails from readers swearing that my books are wrong
> because I tell people to use text/xml instead of text/xsl.
> And I've got a standard from response that tells them to
> complain to Microsoft, not to me because I'm right and
> Microsoft is wrong.
Well, that's the danger of writing a book I guess ;-).
> No, my article was quite clear that MSXML does a better job
> than IE does. The problems in IE 55 and 6.0 have all involved
> the IE team deliberately choosing not to be as up-to-date and
> conformant as the XML team allows them to be. These are *not*
> problems in MSXML. They are problems in IE.
This was unfortunately not that clear from the posted article (it
sounded more like the author did not understand the distinction between
MSXML and IE). And I hope that my explanations above help you understand
better now why IE made their decisions in the way they did. I am sure
that they will accept any feedback that for examples request a
compliance level switch in the browser options and may even add it if
enough such requests come in.
<disclaimer>Working for Microsoft but not directly involved in either IE
or MSXML development.</disclaimer>