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

9/9/01 2:28:48 AM, Rick Jelliffe <ricko@allette.com.au> wrote:

>No,  they chose to penalize everyone else's XML systems. If that IE
>parser accepts something and Oracle's correctly finds the error,
>are the punters supposed to know that MS messed up and Oracle is correct?
>(Or any other example, such as Sun's parser etc.)  Why isn't this just
>"embrace and extend", which the rest of us are sick of. 

Exactly.  If one of your customers is already exchanging data with someone using Microsoft's 
"tolerant" software and you now want to start exchanging data with them, you've got a slam-dunk 
business case for using Microsoft's "tolerant" software yourself rather than something standards-
compliant.  In fact, if you're a publicly traded company, you're probably rendering yourself 
vulnerable to a shareholder lawsuit if you don't.  If you're a vendor who wants to compete with 
Microsoft (i.e. be a "nobody ever got fired for choosing us" vendor), then you have to maintain bug-
for-bug compatibility with whatever Microsoft does (and, of course, Microsoft always has the option 
of documenting particular instances of their "tolerant" behavior and taking that documentation to 
the USPTO...).  Now you're back to *exactly* the situation we had with HTML in the mid-to-late 90s, 
where you've got content sources *relying* on content sinks responding to non-well-formed data in a 
precise manner.  Yep, that's embrace and extend.

At the same time, I *can* understand Microsoft's concern that they not just abruptly break something  
that to their customers appears to be "working."  Maybe the solution is for them to offer a time-
limited "bug-compatibility patch" that would extend the "tolerant" behavior long enough, and only 
long enough, for everybody to fix their broken systems.  Customers would have to do something 
explicit to activate the patch, and the activation process would have to warn them that they could 
*not* count on this behavior in the future.