XML 1.1 Spec Hits Some Snags

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."

It's only a candidate specification.

[tomhudson]

<quote;>This specification is being put forth as a W3C Candidate Recommendation of XML 1.1.</quote;>

If you don't like it, keep in mind that you CAN bitch about it and help change this.

version naming

[tomzyk]

Typically, don't version-naming schemes imply something along the lines of: versions x.0, x.1, x.2, etc... are all compatible. And if the next version is NOT compatible, then it should be labeled as "(x+1).0"?

I guess there's no law stating that this must always be the case, but if these two specifications are NOT compatible, then it would make sense that they would name the new one XML2.0 no?

Re:So?

[Trusty Penfold]

If you used those characters for something in a 1.0 compatible file, they will be trashed with a 1.1 compliant processor.

Considering ...

[DigitalDreg]

That IBM gave the world SGML and XML by derivative ....

That a lot of useful data exists on IBM mainframes ....

That EBCDIC doesn't "cleanly" map into Unicode by design like ASCII/UTF-8 does ...

That this benefits IBM users and customers, not IBM because there is no strategic market position related to new-line characters ...

That this was a recommendation reached by a group ...

Let it live and get a life.

Re:One tiny little update ???

[PainKilleR-CE]

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 ?

and, as an IBM rep pointed out in the article, XML documents are supposed to specify what version they're using at the top of the document. Any proper XML parser should read that it's 1.0 and interpret the newline character as 1.0 would.

2 line summary

[Shagg]

1) XML 1.0 does not follow the Unicode spec
3) XML 1.1 makes a change so that it does follow the spec

What's the complaint again?

What do they mean, "XML 1.0 chokes"?

[st. augustine]

Does anyone have a link to a page explaining what's really going on? Last I heard, XML doesn't even have a concept of newlines -- most of the time all white space gets normalized (collapsed). The only problem that I could see is if the character wasn't part of the spec for white space [xml.com]. Now, people may have written XML software that chokes, but I think that's a slightly different story. So is the problem that the new character shows up as bogus text content in elements? And is that true for all XML processing software, or does software that relies on a proper Unicode engine not have the problem? What's the deal?

The whole thing seems silly

[streak]

As has been pointed out by many people, this whole issue is stilly since 1.1 actually follows the Unicode spec more closely...
(so who's code is broken now? huh?)

Personally I don't see the big deal over XML itself. Its just a way of organizing data hierarchially and expressing it in a nice format (aka a TREE)

I still don't know how people manage to write 500+ page books on it.
Maybe I"m just completely stupid -- please, someone enlighten me to the great wonder that is XML.

Re:Read the Unicode spec....

[Anonymous Coward]

Like the man says, read the Unicode specification! Unicode defines a far wider range of characters than simple 7 or 8bit ASCII text can cover, and the à is simply mapped into another Unicode byte pair. You won't loose the ability to use à in your XML documents, you just use Unicode.

*Shrug*

[Fweeky]

If you're using the XML prologue like you're supposed to, your XML 1.0 documents will have:

<?xml version="1.0" ?>

At the top. The parsers will then parse using the XML 1.0 specification and you won't notice a thing.

If you don't use it, tough luck, you should have followed the original recommendation more closely. Lucky for you it's not exactly difficult to automatically process XML documents and add the prologe later.

This is just not that big a deal.

[BobGregg]

As the quote from IBM points out in the article, this issue is just a subset of the larger problem with Unicode compatibility in XML 1.0. And as someone else pointed out, if document creators are using the XML headers appropriately to begin with, then parsers would handle documents correctly anyway. I'm also willing to bet that the percentage of existing XML documents which contains this particular character (0x85), and which are not already on IBM mainframes, is *extremely* small.

Face it: this just isn't that big a deal. It's good for industry acceptance and propagation of the standard, at very low cost. Move along, there's nothing to see here.

Re:What about poor old Acorn users?

[gorilla]

The Atom, which the BBC was based upon came out in 1979.. At that time there wasn't an IBM PC, and the world was very diverse. You could choose Apples (0D), CP/M (0D,0A), Unix (0A), Primos (8A), VMS - which is either records or 0D. Also, it was quite rare for files to be shared amongst different systems - a file created on an Apple would stay on an Apple forever. A decision which looks strange in 2002 looks as sensible as any other option in 1979.

Additional Newline Character, not a Replacement

[Anonymous Coward]

Don't get too worked up about this. They aren't deleting any newline characters like \n. Just adding one to the list that XML considers whitespace.

Re:Simple Solution

[Anonymous Coward]

Allright Einstein, so how do you know when the line describing the overriding ends?

Crying wolf

[Salamander]

The real issue here is standards-committee wankery and the tendency of some people to accuse anyone who doesn't agree with them 100% of being proprietary, monopolistic, etc. This is exactly the sort of non-issue that doesn't deserve such rhetoric, and those who insist on crying wolf should be ejected from the process until they learn that "collaboration" doesn't mean "we rubber-stamp your ideas just because they're yours".

Re:The whole thing seems silly

[dossen]

The great thing about XML is all the other stuff (XSL,XPath...) that comes with it. And all the implementations for various languages, leaving you free to code your application, instead of having to deal with data formats.

As an example take programX versions 1.x and 2.x, and suppose they use different file-formats (perhaps a feature in 2.x revealed something profoundly broken in the 1.x format).
Now the customers need to convert their data (perhaps even both ways, while they change their installations (and their customers/partners/suppliers/... do the same)).
For that end you must write a conversion, and a program to execute the conversion.
In XML the conversion would be an XSL-stylesheet and the program would be mostely of-the-shelf, saving you the trouble of writing your own conversion program (you would of cause combine the conversion and the "driver" program, right? There will never be a 3.x, right? And validating that your conversion is correct? Naaahhh... Real men trust their code, right?).

Stuff like that is the reason why XML is nice for a data-format.

Mod Article -1 Troll

[kalidasa]

This is just a way to spark a holy war "my newline character is better than yours" debate. The proposal makes perfect sense - it brings XML into line with Unicode and ISO-10646.

Re:One tiny little update ???

[smallpaul]

Considering what some other vendors have done to standards, one tiny addition (which is an improvement) proposed by IBM shouldn't be a big deal.

Two wrongs make a right?

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.

I don't know what that means. This change was requested by IBM and only IBM. As far as I know, no IBM customers have even stood up and asked for it publically (I could be wrong).

Is anyone that worried about adding a new EOL character in 1.1 that XML 1.0 "chokes" on ?

Obviously some people are [xml.com]. Let's keep in mind that there are millions of XML parsers out there and they work together in large part because there is only one version of XML. Now there are two and it will take years to roll out the new parsers universally.

Re:One tiny little update ???

[poot_rootbeer]

And what will an XML 1.0 parser ("millions served") do with an XML 1.1 document?

It should reject it as unsupported, and you should upgrade your parser to one that supports the 1.1 standard.

I think everyone agrees that the XML standards should be backwards-compatible, but you seem to be asserting the idea that it should be FORWARD-compatible and that a parser written today must correctly handle all future revisions that might ever be made, which is ludicrous.

Re:The other side of the argument

[Anonymous Coward]

Updating all of the XML parsers in the world is really expensive


Ummmm.... Updating all the XML 1.1 parsers in the world would be fairly easy at this time. (seeing that the spec isn't final, there isn't any such thing as an XML 1.1 parser yet)

This change wouldn't require any change to the existing XML 1.0 parsers since it is an XML 1.1 feature.

Or you can think about it a little more...

[GCP]

...and you can help support it. The complaints I keep reading are all about how tough it will be for those poor XML tools makers. As an XML tool maker, I assure you that this upgrade is no sweat. No one with the technical skill to create a serious XML tool is going to be challenged by this. The universality goals of Unicode and XML mesh very nicely and it's worth continuing to incorporate the lessons learned by each into the other.