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

>undermines one of the core principles that makes XML usable -
>that data is either WF or it's crap.  The next step will be to

Well, I tend to agree with that mentality; implement the treaty 100% or
not at all.  That is a pretty broad principle, though.  In this very
specific instance, reasonable people will argue that "fatal" error is
draconian, and maybe the WF should distinguish between this and more
"serious" WF issues.

You will recall:

I would also point out that extensive real-world experience since the
publication of XML 1.0 spec has been that people *do* create XML
documents with things like section markers and other common ASCII
characters in the low value range.  It happens all the time, regardless
of "principle" that is supposed to make it not happen.

Furthermore, I think that it getting on thin ice to say authoritatively
that the browser should refuse to show the users those files.  Yes, we
can all agree that "data is either WF or it's crap."  But it is kind of
a stretch to say that "it's crap == don't show the file."  Nothing in
1.0 spec says that the system should do everything in it's power to
prevent the user from ever looking at the content of the file if the
file has a WF violation.  Maybe IE could put a status-bar message that
said "BTW, this file is not really XML, it is crap".  But IE is capable
of displaying all sorts of files, not just XML files, so what is wrong
with IE displaying the file that the user asked it to display?

Honestly, I think we agree on the spirit of the WF constraints.  These
are a good tool to make sure that vendors don't end up producing XML
that breaks one another's parsers.  On the other hand, people use XML
because it is supposed to be simple.  People write ksh scripts that
'echo' and 'cat' XML files together; people use COBOL and slap tags
around existing data to produce XML.  And do you want to know a secret?
The guy who wrote the ksh script that ended up sticking a section marker
somewhere in his XML file is not the kind of guy who will understand
when you tell him "your file has been deleted because you violated
section blah.diddly.blah of document protocol c16".  So the question
isn't about vendors producing such documents; we know that is bad.  But
what do vendors do when someone tries to do something with such a file?
I do not believe that the WF constraints are a tool to beat all of the
users in the world out of their ignorance of the enlightened standards.
If what you are saying is that "a document which has character 0x05 in
it is *not* XML", then I will agree with you.  And I will also ask why
you are complaining about it then.  I can also *gasp* open
not-well-formed XML in notepad.  And I just tried the following:

<?xml version="666" !>

which contains major errors, and notepad and IE *both* opened it just
fine!  Heck, IE even opened a ZIP file, which is *definitely* no
resemblance to well-formed XML.  The fact is, I do not believe that the
spec requires the web browser to bomb on people who want to view such
files, and I know for certain that users don't want that.  Maybe the
browser should pop up a warning or something, but let's not act like
this is a black-and-white issue.