XML 1.1 Spec Hits Some Snags 259
oever writes "News.com reports that the new XML 1.1 specification defines a new newline character, making it incompatible with the 1.0 specifiation. Apparently, IBM has been pushing the new character to avoid having to modify their software, thereby invalidating everybody else's XML software."
MS Office (Score:1, Interesting)
Simple Solution (Score:3, Interesting)
One tiny little update ??? (Score:5, Interesting)
IBM has contributed so much, it's only natural that some changes might be characterized in the news as benefitting them more than other parties. Is anyone that worried about adding a new EOL character in 1.1 that XML 1.0 "chokes" on ?
Re:So? (Score:2, Interesting)
IBM would appear to be right, too, when they note that an application should look at the version identifier which is present at the top of the XML stream.
Here's A Good Point (Score:5, Interesting)
"The truth is that there are a lot of IBM mainframe systems out there, and they're very important," said Ronald Schmelzer, an analyst with ZapThink. "The truth is that this is not really for IBM's benefit, it's for IBM's customers' benefit. And I think that's fair. An international standard shouldn't change for the benefit of a company's future project, but it's clear that end-of-line characters are not a strategic business strategy for IBM."
CRLF in EBCDIC (Score:4, Interesting)
New Newline Character? (Score:4, Interesting)
End of Line For XML? (Score:1, Interesting)
Re:Read the Unicode spec.... (Score:3, Interesting)
Re:version naming (Score:4, Interesting)
Not really. The change isn't exactly huge; it makes XML a bit more consistant with regard to UTF, but I don't see it breaking anything other than for those who both:
TBH if you were that lax in specifying your XML version and characterset, and then made use of non-printable characters that actually had known uses in the default charset, you deserve everything you get.
Re:Here's A Good Point (Score:1, Interesting)
'Here's A Good Point (Score:5)
by LISNews on Friday October 18, @10:28AM (#4478295)
(User #150412 Info | http://www.lisnews.com)
From the article, which kind of put it into perspective for me:
"The truth is that there are a lot of Microsoft systems out there, and they're very important," said Ronald Schmelzer, an analyst with ZapThink. "The truth is that this is not really for Microsoft's benefit, it's for Microsoft's customers' benefit. And I think that's fair. An international standard shouldn't change for the benefit of a company's future project, but it's clear that end-of-line characters are not a strategic business strategy for Microsoft."
Re:Full Details (Score:5, Interesting)
So anyway, I read it. Surprise the surprise, the guy doesn't actually offer any actual examples of where this change would actually cause a break in itself. All he basically does is cry that 0x85 is designated as a new line character, and how dare IBM do such a thing! Then he goes into a rant about IBM, monopolies and patents. Uh huh.
The fact is that 0x0085 is designated as NEL (NEw Line) as part of the Unicode specification. XML 1.1 allows the use of Unicode, which XML 1.0 did not. Therefore, if you are using XML 1.1, and you are using 0x85 and expect to see a grave a, your document isn't a Unicode compliant document anyway, and you shouldn't be complaining that a non compliant document doesn't work with a compliant parser.
If all these people want to use 0x85 in their XML 1.1 documents, then they'll have to properly convert them to Unicode as the specification allows. Surprising, that.
Re:New Newline Character? (Score:2, Interesting)
Because ASCII doesn't work for the character sets that over 50% of the world's (literate) population reads and writes. Hence the Unicode standard, which of course tries to make it's overlap with ASCII compatible when possible.
since when is xml whitespace-dependant? (Score:2, Interesting)
Re:Full Details (Score:2, Interesting)
And you know what? I think an XML v1.1 document would be incompatible with any non-updated program, no matter what the changes in v1.1 are -- for if the program wasn't upgraded, it can't know what XML v.1.1 means. And there must be some difference, otherwise it wouldn't have a different version number
Jeroen
The other side of the argument (Score:4, Interesting)
The Slashdot commentary has been pretty one-sided so I'll try and address the other side. First, IBM has said that this fix is for their mainframe customers, not for themselves. But nobody in the XML world has heard from these customers. As far as I know, no user has submitted a request for this NEL feature. No user has sent a message to the many XML mailing lists. No user has posted to Slashdot. Updating all of the XML parsers in the world is really expensive and if the mainframers don't care enough about the problem to storm the gates then maybe it isn't hurting them that badly. So from a democratic point of view, we're going to make life harder for the people who care enough to scream out loud in order to make life easier for the small minority who perhaps are not even that badly impacted.
Further discussion [xml.com] is on xml.com.
Upgrading OS vs Upgrading XML 1.1 (Score:2, Interesting)
If IBM problem is they don't want to force everyone to update their Mainframes and cause them a head ache...but won't they still have to upgrade their Mainframes to support XML 1.1 with new XML 1.1 compatible parsers?
Re:One tiny little update ??? (Score:3, Interesting)
And what will an XML 1.0 parser ("millions served") do with an XML 1.1 document? When your IBM mainframe serves up 1.1 data with NEL to my Windows 98 with IE 5.5, IE will complain that the document is not well-formed. This means that there is a period of time where the XML world is split. It will be a LONG time before these mainframe users will be able to use NEL and confidently send the data to anyone else. It might have been cheaper to just fix the software.
I don't work for IBM, but I agree (Score:2, Interesting)