RE: XML Blueberry

[Elliotte Rusty Harold <elharo@metalab.unc.edu>]

At 11:21 AM -0400 6/21/01, Mike.Champion@SoftwareAG-USA.com wrote:

Yeah yeah yeah ... but for better or worse, there is an AWFUL lot of 
text and software out there that uses those conventions. Most of it 
is hidden in the machine rooms of the world, out of sight and mind of 
ordinary nerds like most of us, but it's there nonetheless ...


But none of this data is XML! If they're going to convert it to XML, 
changing the line endings is the least of their worries.

and XML is at least being marketed to the people who use it as a way 
to help them communicate with the rest of the world. The authors of 
XML very sensibly chose to respect the line ending conventions of 
Unix, MS, and Macintosh. These were all set "by fiat", no?

Actually carriage return and line feed are part of the ASCII 
standard. Doubtless that's based on somebody's old character set that 
predates both Apple and Microsoft. Nonetheless it was an agreed upon 
part of a standards process. IBM's EBCDIC mess wasn't, and that's 
caused no end of pain over the years. I can only hope that this is 
the last time we'll have to slay the EBCDIC beast.


   Were Microsoft's line ending conventions established and maintained 
by any more democratic and non-monopolistic process than IBM's?

Actually yes. The carriage-return linefeed pair is enshrined by the 
very democratic IETF as the standard line ending convention for most 
network protocols. I doubt this mattered to Microsoft, but the de 
facto case is that \r, \n, and \r\n are all much better supported and 
standard than the extra cruft IBM is trying to push out.


What is so wrong with correcting some small oversights on the part of 
the XML 1.0 WG *before* there is so much XML software out there 
written by companies that are out of business, or for which the 
source code has been lost, that it really does become economically 
impossible to break it?

Because we don't need to do it. It will break existing software and 
systems. We need to draw a line in the sand and say we will not 
change XML just to make one company's job easier. IBM can fix their 
own systems. Changing XML is not necessary to support IBM and IBM's 
customers.

If IBM had made this argument pre-XML 1.0 I'd be a lot more 
receptive. But I do not see a sufficiently compelling need to break 
all the existing software now just to support this.

I don't know enough about the mainframe world to state definitively, 
but I strongly suspect that small changes to XML will cause much less 
total disruption than asking for changes by IBM (which they can 
obviously afford!) *and* the corresponding updates by all their 
customers.  I suspect that we will all be better off in the long run 
by making XML mainframe-friendly than demanding that the mainframes 
become XML-friendly.


I totally disagree. What happens when Oracle comes along and says 
they need a change to support their software? (This is happening now 
in the Unicode world.) What happens when Apple wants a change to 
support Macs? Or Microsoft wants a change to support their systems? 
Where does it end?

XML has been carefully designed so that it's totally implementable 
across a range of platforms. XML works on mainframes today. IBM just 
wants us to adjust the world around it rather than themselves doing 
the not-all-that-complex job of allowing different line ending 
conventions in their text editors and other tools.

-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+