[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bad News on IE6 XML Support
- From: Benjamin Franz <firstname.lastname@example.org>
- To: Michael Rys <email@example.com>
- Date: Mon, 10 Sep 2001 12:33:46 -0700 (PDT)
On Mon, 10 Sep 2001, Michael Rys wrote:
> Eric, the excerpt below is what our XML teams are planning on doing
> (look at MSXML and the System.XML support). IE team members (I think)
> are not even reading this list.
> However, data outlives code, so once you allow people to store data in a
> certain form, you simply cannot disallow them. Warning is an option, and
> providing transition periods (that can range several years/decades).
> This does not move in internet time, I am afraid...
Yes, you can. You may not _want_ to do so. It may be politicaly
inconvienent do so. But without question - you can.
Sometimes you have to take the hit on the chin and say to your customers
"This is a bug. We know you may have stored data in form X (and here is a
tool to help _filter_ the problematic data for you before you deliver it
to a client if you absolutely cannot repair your database), but it has to
be changed because that behavior was a bug and your XML _will not_
interoperate with other people if it is not fixed now. And the more data
you store like this the worse it will get."
"Bugwards" compatibilty is precisely why HTML ended up in the mess it was
in a couple of years ago (and still is in to a large extent). Each new
browser had to exactly replicate the _known to be wrong_ behavior of the
previous one. Because rather than fix the problem when there were only a
few _thousand_ web browsers installed, it was left to fester until their
were _tens of millions_ installed.
That is why you bite the bullet _as early as you can_. Because it only
gets worse with time to fester. Trying to save your customers immediate
pain by _continuing_ to do the wrong thing makes the situation worse on
the long term as their pain becomes everyone _else's_ pain for years to
Good work is always done in defiance of management.
---R. Woodward (quoted by R.L. Peskin <firstname.lastname@example.org>)