Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
News

XML 1.1 Spec Hits Some Snags 259

Posted by Hemos from the battle-in-the-works dept.
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."
This discussion has been archived. No new comments can be posted.

XML 1.1 Spec Hits Some Snags More

XML 1.1 Spec Hits Some Snags

Comments Filter:
  • <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.

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

  • What? No newline? (Score:3, Funny)

    by Distinguished Hero ( 618385 ) on Friday October 18, 2002 @09:21AM (#4478231) Homepage
    That explains why my website was one long paragraph.

  • Simple Solution (Score:3, Interesting)

    by Anonymous Coward on Friday October 18, 2002 @09:22AM (#4478234)
    Why don't they make new-lines overridable? Then IBM can put the override at the beginning of their files.

  • Read the Unicode spec.... (Score:5, Informative)

    by vidarh ( 309115 ) <vidar@hokstad.com> on Friday October 18, 2002 @09:22AM (#4478238) Homepage Journal
    Unicode 3.2 define 0x85 as a newline character. This change just make XML follow the Unicode spec, which isn't unreasonable considering that the parser is expected to use Unicode internally (or to act as if it does).

    • Re:Read the Unicode spec.... (Score:5, Informative)

      by gorilla ( 36491 ) on Friday October 18, 2002 @09:59AM (#4478538)
      It's more complicated than that. Unicode has
      2029 - paragraph seperator
      2028 - line seperator
      000D - CR
      000A - LF
      0085 - NEL (Next Line)
      Any of these could be interpeted as the end of a logical line.
    • Doesn't make this XML files uneditable with most editors, like vi, pico and gedit? They all use \n (byte 10) as newline character.

      • Re:Read the Unicode spec.... (Score:2, Informative)

        by Anonymous Coward
        Ah, dude, the newline is the least of your problems. 2-byte Unicode characters are not exactly backwards compatible with 1-byte (or, pedantically, 7-bit) ASCII.

        • Re:Read the Unicode spec.... (Score:5, Informative)

          by innate ( 472375 ) on Friday October 18, 2002 @11:07AM (#4479123)

          There are no 2-byte Unicode characters, only encodings (such as UTF-16) which use two or more bytes to represent each character. Some Unicode characters, those not in the Basic Multilingual Plane (BMP), require more than two bytes to represent in UTF-16.

          And 7-bit ASCII is a strict subset of UTF-8 encoding. UTF-8 encodes each character to one or more bytes, with characters up to 127 defined the same as in ASCII. If your text is strict 7-bit ASCII, it is also a UTF-8 file.

          You could also use UTF-32 (UCS-4), which represents each character as 4 bytes, but that is overkill for most applications.

          The main problem with multibyte encodings such as Shift-JIS and Big 5 was lead-byte detection: you couldn't jump into the middle of a string and determine if you were looking at the only, first, or second byte of a character. You had to start parsing at the beginning of the string in order to synchronize your character detection. Unicode has done away with this by strictly defining the lead byte ranges in such a way that there is never any ambiguity.

        • Uh, dude, Unicode characters are not necessarily 2-byte. UTF-8 characters are 1 byte if ASCII (real ASCII, the "pedantic" 128-character set), 2 byte or more (up to 6 or 8 bytes, iirc) if not. UTF-16 characters are either 2 bytes or 4 bytes. UTF-32 characters are all 4 bytes. Read the spec.

      • no. it's fine. (Score:4, Informative)

        by MenTaLguY ( 5483 ) on Friday October 18, 2002 @10:57AM (#4478985) Homepage

        Doesn't make this XML files uneditable with most editors, like vi, pico and gedit? They all use \n (byte 10) as newline character.



        No. XML is defined in terms of Unicode, but XML files can be stored in any encoding with a known mapping to Unicode.



        Most XML files these days are using iso-8859-1 or UTF-8, both of which manage fine in vi/pico/gedit.



        chars 32-127 are identical in ASCII and Unicode, and iso-8859-1 is exactly identical to the bottom 8-bits worth of Unicode.



        Also, UTF-8 is an encoding of the full Unicode range that is backwards-compatible with 7-bit ASCII.



        in any case, note the entry for LF in your parent post -- 000A (hex) = 10 (decimal).

        • Just to clarify, what happens to a 0085 (NEL) character when a Unicode file is saved in an iso-8859-1 or UTF-8 encoding?
          • It's the same thing that happens any time you take codepoints across character sets.

            iso-8859-1:

            NEL (from EBCDIC) doesn't exist in iso-8859-1; what character gets used instead is up to the discretion of the tool doing the conversion. Since Unicode defines 0x0085 as a whitespace character, the tool could know to substitute another if that was desired.

            UTF-8:

            It's a non-lossy encoding of Unicode. All characters above 0x007f get stored as multi-byte sequences. 0x0085 becomes 0xc2 0x85.

          • UTF-8 (Score:3, Informative)

            by MenTaLguY ( 5483 )
            If you want to know more about UTF-8, see RFC 2279 [faqs.org].

      • Re:Read the Unicode spec.... (Score:5, Informative)

        by julesh ( 229690 ) on Friday October 18, 2002 @10:57AM (#4478989)
        No, not really. It means that *some* XML files can't be edited with these editors. But then that was true already; some might have used \r or some other of the list of characters.

        What it *does* mean is that editors on other systems than Unix are able to edit XML files. It means I can create an XML file in DOS 'edit' which uses \r\n, or on a mac with an editor that might use \r, or on (apparently) an IBM system where the standard text editors use \u85.

        This is absolutely essential. It does however mean that in order to support *all* XML files, you need to recognise *all* of those line endings. As always, its easier to support a subset, but harder to support everything. However the fact that existing software works at all is very important, so I think they're moving in the right direction.

    • There are all kinds of funny characters that XML does not support. You can't use zero-width or non-breakingspaces as whitespace either. You can't use circled numerals as numbers. etc. NEL is only special because IBM is a big enough company to get attention paid to its legacy software. "Legacy software" and "unicode" seem like an odd mix to me anyhow. Couldn't NEL problems be fixed in a transcoder?

  • So? (Score:5, Informative)

    by Anonymous Coward on Friday October 18, 2002 @09:25AM (#4478261)
    1.0 : To simplify the tasks of applications, the characters passed to an application by the XML processor must be as if the XML processor normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.

    1.1 : To simplify the tasks of applications, the characters passed to an application by the XML processor must be as if the XML processor normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating all of the following to a single #xA character:

    • the two-character sequence #xD #xA
    • the two-character sequence #xD #x85
    • the single character #x85
    • the single character #x2028
    • any #xD character that is not immediately followed by #xA or #x85.


    I don't get it, whats the problem here? Surely the 1.1 spec simply extends the available EOL characters. It certainly doesn't remove any existing characters that are present in the 1.0 spec. How does it break backwards compatability?

    • Re:So? (Score:2, Insightful)

      by Trusty Penfold ( 615679 )
      If you used those characters for something in a 1.0 compatible file, they will be trashed with a 1.1 compliant processor.

      • Re:So? (Score:2, Interesting)

        by Anonymous Coward
        Fair point, but how many people do you think have actually used those characters in an XML1.0 document?

        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.

    • First off, unicode 85H is NEXT LINE; ASCII 85H is ellipses. unicode 2028H is LINE SEPARATOR. AH and DH are the infamous CR/LF which annoy MS/UNIX text convertors.

      Anyways, it sounds like a problem comes up here:
      must be as if the XML processor normalized all line breaks in external parsed entities (including the document entity) on input, before parsing,

      That seems to be the sticking point there.

      I suppose the charset is specified in the document, but then again I'm not sure how literally they intend implementors to take the phrase "before parsing", since getting at the charset description involves some degree of parsing the document

      • Re:For those missing the problem, also à (Score:5, Informative)

        by Anonymous Coward on Friday October 18, 2002 @10:20AM (#4478718)
        From the XML 1.1 spec

        The W3C's XML 1.0 Recommendation was first issued in 1998, and despite the issuance of many errata culminating in a Second Edition of 2000, has remained (by intention) unchanged with respect to what is well-formed XML and what is not. This stability has been extremely useful for interoperability. However, the Unicode Standard on which XML 1.0 relies for character specifications has not remained static, evolving from version 2.0 to version 3.1 and beyond. Characters not present in Unicode 2.0 may already be used in XML 1.0 character data. However, they are not allowed in XML names such as element type names, attribute names, enumerated attribute values, processing instruction targets, and so on. In addition, some characters that should have been permitted in XML names were not, due to oversights and inconsistencies in Unicode 2.0

        So XML 1.0 used Unicode 2.0, but not properly. XML 1.1 fixes that, and defines that all Unicode 3.2 byte pairs are now valid when used in an XML document. As part of this change, XML 1.1 also correctly allows the use of the Unicode 0x0085 NEL character as an EOL marker, which is totally compliant and consistent with the Unicode 3.2 specification.

        In other words, if you're using any character encoding other than Unicode 3.2, your XML document isn't compliant with XML 1.1 and you shouldn't ever expect ISO-Latin 0x85 to be displayed as an ellipses.

  • version naming (Score:3, Insightful)

    by tomzyk ( 158497 ) on Friday October 18, 2002 @09:25AM (#4478262) Journal
    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:version naming (Score:4, Interesting)

      by Fweeky ( 41046 ) on Friday October 18, 2002 @10:06AM (#4478589) Homepage
      if these two specifications are NOT compatible, then it would make sense that they would name the new one XML2.0 no?

      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:
      • Failed to specify a prologue (and hence charset, meaning they accepted the default utf-8), and;
      • Actually used #x85 or #x2028 to encode anything useful other than newline.

      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.

  • End of Line (Score:3, Funny)

    by notestein ( 445412 ) on Friday October 18, 2002 @09:26AM (#4478270) Homepage Journal
    If we don't allow the IBM EOL in XML 1.1 ...
    How will we ever communicate with Master Control Program?

    End Of Line

  • One tiny little update ??? (Score:5, Interesting)

    by Dave21212 ( 256924 ) <dav@spamcop.net> on Friday October 18, 2002 @09:26AM (#4478273) Homepage Journal
    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. Sure, it feeds the news hounds, but seriously, compare the scale of the impact of one desirable change to all the suffering caused by other such changes in emerging standards (Microsoft's in particular).

    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:One tiny little update ??? (Score:5, Insightful)

      by PainKilleR-CE ( 597083 ) on Friday October 18, 2002 @09:33AM (#4478321)
      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.

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

        • Re:One tiny little update ??? (Score:5, Informative)

          by PainKilleR-CE ( 597083 ) on Friday October 18, 2002 @11:42AM (#4479486)
          The problem is that the data with the NEL character already exists, and is already generating these types of errors when it's translated into XML (or when XML is generated on these mainframes). From the original change proposal by IBM:

          Problem areas include:

          * Processing XML documents or DTDs generated on OS/390 systems, with XML 1.0 compliant parsers.
          * Processing XML documents or DTDs, using native OS/390 system tools.
          * Processing XML documents or DTDs retrieved from OS/390 database or file systems, in non-OS/390 environments.

          XML documents that contain [NEL] characters are declared invalid or not well-formed by XML 1.0 compliant parsers.

          Essentially 'just fix the software' involves operating system-level changes as well as possibly changes to most software that interprets NEL characters on that OS. As it stands, they're going to have a problem anyway, and it's probably best to simply add the change to the XML standard to fix what was essentially an osmission in the 1.0 standard.
        • Where did you get the idea that the software is broken?
        • 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.

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

      • Now there are two and it will take years to roll out the new parsers universally.
        You can't blame this on the NEL issue. XML 1.1 will arrive sooner or later regardless of now the NEL issue ends up.

  • XML rant. (Score:2, Funny)

    by Anonymous Coward
    <rant about="IBM" why="'FOR BREAKING COMPATIBILLITY">IBM SUCKS</rant>

  • What about poor old Acorn users? (Score:3, Informative)

    by PhilHibbs ( 4537 ) <snarks@gmail.com> on Friday October 18, 2002 @09:27AM (#4478281) Journal
    I don't know if it's still the same in RiscOS, but the BBC Micro used 0x0A+0x0D as it's end-of-line marker. Why doesn't XML support this? If 1.1 is going to modify the end-of-line specification, then this is the perfect time to correct this glaring omission.
    • And what about old telex machine users that used x0A0A0D (CRCRLF) in case the carrige got stuck?

      You may think this is funny. but there is still some software out there that assumes a mechanical teletype at the far end, sending weather bulletins to Africa, football scores to the Beeb, etc.

  • Here's A Good Point (Score:5, Interesting)

    by LISNews ( 150412 ) on Friday October 18, 2002 @09:28AM (#4478295) Homepage
    From the article, which kind of put it into perspective for me:


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

  • Considering ... (Score:5, Insightful)

    by DigitalDreg ( 206095 ) on Friday October 18, 2002 @09:30AM (#4478301)
    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.

  • 2 line summary (Score:5, Insightful)

    by Shagg ( 99693 ) on Friday October 18, 2002 @09:39AM (#4478367)
    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?

  • News?? (Score:2, Funny)

    by ceeam ( 39911 )
    In other news - Julius Caesar stabbed and died.
    Anyway - for how long 1.1 draft has been out?

  • What do they mean, "XML 1.0 chokes"? (Score:5, Insightful)

    by st. augustine ( 14437 ) on Friday October 18, 2002 @09:42AM (#4478395)
    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?
    • Actually your understanding of whitespace in XML is almost completely incorrect.

      Many XML applications ignore whitespace (after parsing). XML parsers are prohibited from deleting any whitespace that might be part of the data in a document. The xml:space attribute allows a document to indicate places where the author or encoder encourages normalization of space in some way.

      This is all clearly explained in the standard itself (W3c XML pages [w3.org]).

  • Complain (Score:3, Informative)

    by almeida ( 98786 ) on Friday October 18, 2002 @09:42AM (#4478399)
    Don't like it? Complain [mailto]. Comments can be viewed here [w3.org].

  • CRLF in EBCDIC (Score:4, Interesting)

    by spacefight ( 577141 ) on Friday October 18, 2002 @09:44AM (#4478407)
    is 0x156C in my programming area, 'nough said. EBCDIC is still live. Did you know that about 90% of todays enterprise data is stored in EBCDIC chars? You better update the XML specs :)
    • Did you know that about 90% of todays enterprise data is stored in EBCDIC chars?

      That sounds like a tautology, because I bet you define "enterprise data" as any data that is stored in a mainframe.

  • New Newline Character? (Score:4, Interesting)

    by RAMMS+EIN ( 578166 ) on Friday October 18, 2002 @09:44AM (#4478413) Homepage Journal
    Anybody care to explain to me _why_ we need so many different newline characters | sequences? I see a point in having a single \x0a character, because a newline is one character. I see a point in having \x0a\x0d and \x0d\x0a, because they represent more accurately how a typewriter does it (and conform better to the original ASCII standard, I think). However, one of these is kind of redundant, and history seems to have decided that this is \x0a\x0d. But why, for goodness's sake, do we need all those others??? Why is it that people always do things their own way instead of following standards that work fine???
    • I see a point in having \x0a\x0d and \x0d\x0a, because they represent more accurately how a typewriter does it (and conform better to the original ASCII standard, I think). However, one of these is kind of redundant, and history seems to have decided that this is \x0a\x0d. But why, for goodness's sake, do we need all those others??? Why is it that people always do things their own way instead of following standards that work fine???

      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.
      • ``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.''
        Note that I said ``standards that work fine''. ASCII doesn't work fine, because it can only represent languages that use the latin alphabet with no accents decently. However, the newline/LF and CR in ASCII work fine, no matter what language, as far as I can see. So my question remains...why add to that? Does this new newline character server another function besides indicating a newline, so that it is semantically different from the old newline?

        ---
        Know Your Sysadmin [gnu.org]

    • Re:New Newline Character? (Score:5, Informative)

      by gorilla ( 36491 ) on Friday October 18, 2002 @10:41AM (#4478877)
      Each of them has a different function. 000A and 000D are for compatability with ASCII. 0085 is for a unified character to replace the 000D 000A pair used on some OS's. However, some programs (eg notepad) use line breaks when they really mean paragraph seperators, so Unicode defined two codes which mean REAL line seperator, and REAL paragraph seperator. This report [unicode.org] explains it quite clearly.

  • Karma, please (Score:2, Redundant)

    by p3d0 ( 42270 )
    Here's more info. [w3.org]

  • The whole thing seems silly (Score:3, Insightful)

    by streak ( 23336 ) on Friday October 18, 2002 @09:51AM (#4478472) Journal
    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.

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

    • Read the XSLT spec. That gives you some idea of the wonder that is XML.

  • W3C still meeting over IBM resolutions (Score:5, Funny)

    by spoonyfork ( 23307 ) <spoonyfork&gmail,com> on Friday October 18, 2002 @09:51AM (#4478473) Journal

    World Wide Web Consortium still meeting over IBM resolutions

    Posted: Sat, 19 Oct 2002 0:18 AEST

    The five permanent members of the World Wide Web Consortium are meeting overnight in an attempt to agree on a resolution on IBM. W3C diplomats say there are signs HP and Sun are now moving towards a compromise, after weeks of wrangling over the XML issue.

    HP wants clear instructions given to Microsoft that it return to the World Wide Web Consortium before taking legal action, while the Microsoft wants more leeway for itself and its allies. Meanwhile, the HP CEO, Carly Fiorina, has given another strong warning against the use of force against IBM.

    Speaking at the opening of a summit of XML using companies in the Silicon Valley, Mrs Fiorina said legal force must only be used as a last resort. She called for all conflicts to be resolved in ways respecting international law, as this was the only guarantee against what she described as "adventurist" policies.

  • I don't understand why XML 1.0 should choke on this character, should it just see it as any other data?

    The article doesn't explain the technical problems in any depth at all.


  • ... 8 bits should be enough for anybody.

    to paraphrase Bill G.

  • *Shrug* (Score:5, Insightful)

    by Fweeky ( 41046 ) on Friday October 18, 2002 @09:53AM (#4478492) Homepage
    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.
    • <gripe>
      Believe it or not as you will, adding the declaration frequently will cause bad behavior -- if it's XHTML on a browser. Often I've had clients call in, complaining about a site displaying bizarrely, or not at all. The thing that has fixed it has been taking out the XML declaration which, according all the specs that I've seen, is optional.

      The DOCTYPE declaration often causes problems too. Why, I don't know. I just wish all these vendors would get their acts together and get all of the browsers to respond the same for XHTML-compliant pages.
      </gripe>
      • Non-compliant browser.
        • Widely used browser.

          The truth is, you can never just tell a client that a browser is non-compliant and leave it at that. They are using that browser, and the website must match what they should be getting.

          One of our clients had, for some god-forsaken reason, a font named "Georgia" which was some form of Cyrillic. He thought his whole website was gibberish, because in the style sheet we had defined that font as the default font for body text. Even though it was only the case on his computer which had this bizarre font, we had to change it to Times New Roman so that it would display correctly on his browser.

          Not to get on another rant but I have to say, I am a little sick of people who talk about standards and how it's more important to follow the standards than to create solutions that do what clients want, even if they don't comply. Have these people ever created websites for others for money? If so, they must have discovered by now that the mantra "The customer always thinks they're right" applies in their line of work, too. I don't have the luxory of telling some client to "shove off" if they don't want to comply with my standards-following ideals. I have to give them what they want.

          • Which is all fine.

            But it doesn't make the browser any more compliant.

            Credit where credit's due, that's all I'm saying.

  • XML 1.1 - Problem? (Score:5, Informative)

    by Plud ( 612927 ) on Friday October 18, 2002 @09:58AM (#4478532)
    A newline character should have no impact on with respect to backwards compatibility. The only negative impact with regards to a newline character should be contained to poorly written DOM code that parses out all nodes instead of just relavent nodes. Similar issue with SAX. Even if there were a backwards compatibility issue with a new XML spec, most people define their version number in their documents so the parser knows which spec to follow while parsing it.

  • Full Details (Score:5, Informative)

    by Matts ( 1628 ) on Friday October 18, 2002 @09:58AM (#4478536) Homepage
    Full details of why this has the potential to break things are on the XML news site Cafe Con Leche [cafeconleche.org].

    Please read that before making uninformed comments - news.com isn't where you'll find technical information about this problem.

    • Re:Full Details (Score:5, Interesting)

      by Anonymous Coward on Friday October 18, 2002 @10:14AM (#4478669)
      So I want off and read it (Or at least, what appears to be it. There is a rant someway down the page you link to. Is that it?)

      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:Full Details (Score:3, Informative)

        by MenTaLguY ( 5483 )

        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.

        Or specify iso-8859-1 as their encoding in the XML prologue, which they were supposed to do in XML 1.0 anyway.

    • Re:Full Details (Score:2, Interesting)

      by nijhof ( 44330 )
      There is only a rant on that page, no examples.

      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 proposed change (Score:4, Informative)

    by Srin Tuar ( 147269 ) <zeroday26@yahoo.com> on Friday October 18, 2002 @10:01AM (#4478557)
    Rather than reading through the whole spec:
    here [w3.org] is a summary of just the proposed change.


    It seems to comply with unicode just fine, I dont see what the controversy is really.

  • New Line and Characters (Score:5, Funny)

    by JasonSkywalker ( 204047 ) on Friday October 18, 2002 @10:04AM (#4478575)
    Let us not forget that it was New Line that callously yanked Tolkien's loveable Tom Bombadil! It was New Line that turned Arwen into a heroic Nazgul-racing babe-elf! It was New Line that left out poor Glorfindel and his big moment at the river altogether!

    I don't know about anyone else, but I think it's only fitting that a New Line character be messed with.

    ---

  • This is just not that big a deal. (Score:4, Insightful)

    by BobGregg ( 89162 ) on Friday October 18, 2002 @10:10AM (#4478622) Homepage
    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.

  • In other news... (Score:4, Funny)

    by T.E.D. ( 34228 ) on Friday October 18, 2002 @10:17AM (#4478697)
    EBCDIC [ic.ac.uk] has won yet another chess game against the Grim Reaper.
  • I'll admit that I don't know much about the technical side of xml (and I really can't see all of the great advantages to it, either), but since when does a parser care about whitespace? Wouldn't it make more sense to let the newline character match that of the overlying OS so people can actually TYPE those newline characters? Switching to unicode is fine and dandy, but what about all of those legacy systems that don't support it?

  • Additional Newline Character, not a Replacement (Score:2, Insightful)

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

  • Crying wolf (Score:3, Insightful)

    by Salamander ( 33735 ) <`jeff' `at' `pl.atyp.us'> on Friday October 18, 2002 @10:55AM (#4478963) Homepage Journal

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

  • The other side of the argument (Score:4, Interesting)

    by smallpaul ( 65919 ) <paul AT prescod DOT net> on Friday October 18, 2002 @11:10AM (#4479151)

    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.

  • Mod Article -1 Troll (Score:4, Insightful)

    by kalidasa ( 577403 ) on Friday October 18, 2002 @11:19AM (#4479255) Journal
    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.
  • Okay...maybe I'm not looking at this incorrectly, but...

    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?

  • Who ever heard of an end-of-line character on a mainframe? Everything was always fixed length, with the length in the DCB, or variable length, with a length prefix, at least back when I used them. There was a "record mark" character, but that was used back on the 1401's, back in ancient times.
  • I'm dealing with some cross-platform XML these days. It's generally pretty wonderful, but the newline character is something that drives me a bit batty. If anyone can bring some unity to this disunity, I'm sure that all of the XML world and the Java world would be better off. It's an anachronism.

  • Some clarifcation (Score:3, Informative)

    by kune ( 63504 ) on Friday October 18, 2002 @12:16PM (#4479830)
    The problem is cause be the EBDIC code. It has special codes for CARRIAGE RETURN (CR), LINE FEED (LF) and NEW LINE (NL). The problem is now how you convert NL into UNICODE, you could map it to LF, but that can't be mapped back. You could als map it to LINE SEPERATOR U+2028, but IBM seems to think that mapping it the NEL (New Line) U+0085 control character is appropriate. This is supported by UNICODE standard annex UAX #13. However in UAX #14 U+0085 has not the line breaking property, so there is still some inconsistence in the UNICODE standard. But I don't think this is an major issue. It does mean only, that you will have problems to edit XML-documents generated in EBCDIC in some of the worser editors. We have lived all the years with the DOS CRLF/UNIX LF problem, so we will survive this too.

  • XML, XML... LISP! (Score:3, Funny)

    by panserg ( 555671 ) on Friday October 18, 2002 @12:48PM (#4480152) Homepage
    Compare the elegance of LISP brackets to overbloated XML tags. Compare the ability to share same syntax with code and data in LISP with oversimplified XML tags. Make a conclusion.

Slashdot Top Deals

"Pok pok pok, P'kok!" -- Superchicken

Close