Slashdot Mirror


A Bunch Of XML Recommendations

KjetilK writes "During the past couple of days, the World Wide Web Consortium, have advanced several core XML-specifications to Recommendations. You have the Extensible Markup Language (XML) 1.1 and Namespaces in XML 1.1 as well as XML 1.0 Third Edition. In addition, XML Infoset Second Edition is now a Recommendation and VoiceXML 2.0 is now Proposed Recommendation."

5 of 22 comments (clear)

  1. XML 1.1 Not necessarily a good idea by Anonymous Coward · · Score: 2, Informative

    I'm just going to syndicate Elliote Rusty Harold [scroll down to the Feb. 5th entry] on this one and pass along his suggestion that you don't use XML 1.1; Xerces 2.6 will process it, but most things won't, and most of the benefits of what's new in XML only apply if you're putting your documents into a few (mostly Asian) languages.

    1. Re:XML 1.1 Not necessarily a good idea by axlrosen · · Score: 2, Informative

      most of the benefits of what's new in XML only apply if you're putting your documents into a few (mostly Asian) languages.

      And it's not Chinese or Japanese or Korean, it's more esoteric languages like Mongolian, Yi, Cambodian, etc. And the benefit only applies to element and attribute NAMES - you can already use these characters in text VALUES in XML 1.0.

      XML 1.1 also helps people who use IBM mainframes, or who interoperate with them.

  2. XML 1.1 incompatibility by kherr · · Score: 5, Informative

    Elliotte Rusty Harold has a persuasive argument against XML 1.1. He is someone who's opinion should be considered. He writes very thorough, good books on XML and has created the most excellent XOM (same goal as DOM, but easy to use). He also keeps us current on the XML world at Cafe con Leche.

    1. Re:XML 1.1 incompatibility by fm6 · · Score: 3, Informative
      I have a lot of respect for ERH. As you say,he's written some really good books, including the absolute best XML-for-beginners book. And I sort of agree with him that a 1.1 spec is premature. But I think he's kind of gone overboard on this issue. Some points:
      • Although this revision was partially driven by IBM (they needed some changes to do XML in EBCDIC, there are other problems that people wanted to address. ERH seems to think this is all a case of IBM throwing its weight around -- which is just not true.

      • ERH blames this hassle over an "obsolete" coding on IBM's corporate arrogance. In this, he follows the common wisdom that IBM just ignored the whole EBCDIC/ASCII issue until the PC revolution made a switch to standard character sets unavoidable. I actually believed this stuff myself, until I stumbled onto the real story. Which is that ASCII (which was invented at IBM!) was supposed to be the standard for IBM mainframes, but a series of bureaucratic screwups and bad decisions prevented this from happening.

        Yeah, IBM, should have made the change anyway. But we all how hard it is to change a technical direction once a lot of effort has been put into it. Look at the groddy UI at Slashdot. Look at all the web presence providers (including mine!) who won't upgrade to a taint-safe version of Perl because it would break too much of their code. The examples are endless. You may not sympathize, but you damn well should understand.

      • If you read the 1.1 spec carefully (I recommend the version with highlighted revisions) you'll realize that 1.1 is in no way a replacement for 1.0. People with a lot of 1.0-compliant XML and who don't need to read any 1.1-compliant XML can simply ignore the new spec, if they choose. The 1.1 spec very clearly states that nothing has changed in terms of what parsers should and should not do with XML 1.0. Provided, of course, people remembered to head all their XML files with the mandatory processing instruction:
        <?xml version="1.0"?>
        And if you've read ERH's books, you know to do that!
  3. Re:go standards! by jilles · · Score: 4, Informative

    The list of changes is pretty much limited to being more tolerant to newer unicode specifications (which xml depends on and which werent available at the time xml 1.0 was finalized)and to avoid similar adjustments to the spec in the future. I.e. any well formed xml 1.0 document is also xml1.1 compliant. There may be some exotic xml1.1 documents (using some unicode exotic characters) that are not well formed xml 1.0. This change is very defensible, unless you are willing to freeze the unicode spec four years ago. The changes have no consequences whatsoever for the validity of existing xml documents (correct me if I'm wrong) and they should work exactly the same (namely as specified by the w3c) in xml1.1 processors.

    --

    Jilles