6 ms·

I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this: <p

I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this: <parameter> <name>ApplicationName</name> <value>WhizBang</value> </parameter> ... So that they could pass schema validation and still have some hope of extensibility.

organsnyder 8y ago
Why not just <parameter name="ApplicationName" value="WhizBang"/> ?
- rocmcd 8y ago
  That's the age-old question, isn't it? Your option is better, but XML is very (maybe too) flexible and is bound to be made a mess of.
  - organsnyder 8y ago
    I've seen some pretty messed up schemas in JSON and YAML, too.
- commandlinefan 8y ago
  That's still worse than <ApplicationName>WhizBang</ApplicationName>. Or ApplicationName=WhizBang
hyperman1 8y ago
A few weeks ago, I had about 100 config files (tomcat context.xml) which all needed fixes for common misconfigurations - if they had the misconfigurations in the first place The kind of problem that is just a little bit too hard for search and replace. It was really easy with xslt. The result had all comments preserved. I choose to reformat the files, but keeping whitespace was an option too. Now tell me if you can do that with json,yaml,toml. Most parses simply forget about the comments to begin with. In the same way, if we receive a data transfer in XML and there is a schema, simple validation catches a lot of problems quickly. You'd be surprised how many times a company gives you a schema and then sends you xml which doesn't validate. In JSON, you have to write a program to get even basic validation. Don't get me wrong: XML has problems, some inherited from html/sgml (entities!), and even more after serious abuse by consultants, archicture astronauts and enterprise vendors (SOAP! namespace overuse! 10 XML parsers in 1 app!). But it was also miles better than what came before and I feel the XML hatred pendulum has swung too far. Today, JSON is in vogue, and I've seen enough IT to not swim against the tide. It is a reasonable solution for problems caused by XML abuse. Besides, there is value in going with the majority,even if it only fixes 80% of your problem. But I can only weep for the miserable date, numeric and comment support, and their endless stream of incompatible workarounds. For your parameter example: You can't both strictly validate and have full freedom at the same time. Something has to give a bit. Some less horrible alternatives I've seen: <parameter name="X" value="Y"/> <subsystem name1="value1" name2=value2 ... /> , add newline for each attribute <name>value</name>
- tannhaeuser 8y ago
  What problems wrt entities does XML have that it has inherited from SGML and HTML? Do you mean entity expansion attacks such as million laughs? HTML has only character rather than general entity references, and SGML has had the ENTLVL capacity to bound entity reference nesting since the year 1986. Edit: XML is just a proper subset of SGML by definition, hence it didn't introduce a single thing that wasn't there before. It only introduced XML-style empty elements and DTD-less markup, and SGML was extended in lockstep with XML to support these as well
  - hyperman1 8y ago
    I'd consider user definable entities a problem, as you can't read a file without knowing the DTD. Million laughs is just a very ugly bonus. XML is more than the part inherited from SGML, it's also the XML culture surrounding it. Namespaces are an example of something that created an XML dialect. And of course SOAP, which actually needs the WS-I standard to explain what parts of the WS-* standards to use or ignore, and how to interprete them. And even then 2 WS-I stacks will rarely interop without trouble. Lets not blame SGML for that monstrosity
    - Mikhail_Edoshin 8y ago
      What's wrong with namespaces? These are simply globally unique identifiers that allow us to define and use our own globally unique names and make them passably human-readable. That is: <a:log /><b:log /><c:log /> can mean a math function, a text file that records what's happening, and a cut-off trunk of a tree and there will be no confusion whatsoever. (I really don't get how SOAP is relevant here.)
int_19h 8y ago
XML is verbose, and overcomplicated. But most purported replacements trimmed too much.
spiralx 8y ago
I would definitely use RelaxNG for specifying schemas instead of XSD - it's simpler both to read and write in every case I've tried, and the resulting schema is smaller as well, often by a lot. <element name="addressBook"> <zeroOrMore> <element name="card"> <attribute name="name"> <text/> </attribute> <attribute name="email"> <text/> </attribute> </element> </zeroOrMore> </element> http://www.relaxng.org/tutorial-20011203.html http://www.relaxng.org/tutorial-20011203.html Plus there's a non-XML "compressed" version as well: element addressBook { element card { element name { text }, element email { text } }+ } But I agree that XML like you posted is nasty, it's no harder to write <parameter name="ApplicationName">WhizBang</parameter> instead if you need generic parameters, or <ApplicationName>WhizBang</ApplicationName> if not.

organsnyder 8y ago

Why not just <parameter name="ApplicationName" value="WhizBang"/> ?

rocmcd 8y ago
That's the age-old question, isn't it? Your option is better, but XML is very (maybe too) flexible and is bound to be made a mess of.
- organsnyder 8y ago
  I've seen some pretty messed up schemas in JSON and YAML, too.
commandlinefan 8y ago
That's still worse than <ApplicationName>WhizBang</ApplicationName>. Or ApplicationName=WhizBang

hyperman1 8y ago

A few weeks ago, I had about 100 config files (tomcat context.xml) which all needed fixes for common misconfigurations - if they had the misconfigurations in the first place The kind of problem that is just a little bit too hard for search and replace. It was really easy with xslt. The result had all comments preserved. I choose to reformat the files, but keeping whitespace was an option too. Now tell me if you can do that with json,yaml,toml. Most parses simply forget about the comments to begin with. In the same way, if we receive a data transfer in XML and there is a schema, simple validation catches a lot of problems quickly. You'd be surprised how many times a company gives you a schema and then sends you xml which doesn't validate. In JSON, you have to write a program to get even basic validation. Don't get me wrong: XML has problems, some inherited from html/sgml (entities!), and even more after serious abuse by consultants, archicture astronauts and enterprise vendors (SOAP! namespace overuse! 10 XML parsers in 1 app!). But it was also miles better than what came before and I feel the XML hatred pendulum has swung too far. Today, JSON is in vogue, and I've seen enough IT to not swim against the tide. It is a reasonable solution for problems caused by XML abuse. Besides, there is value in going with the majority,even if it only fixes 80% of your problem. But I can only weep for the miserable date, numeric and comment support, and their endless stream of incompatible workarounds. For your parameter example: You can't both strictly validate and have full freedom at the same time. Something has to give a bit. Some less horrible alternatives I've seen: <parameter name="X" value="Y"/> <subsystem name1="value1" name2=value2 ... /> , add newline for each attribute <name>value</name>

tannhaeuser 8y ago
What problems wrt entities does XML have that it has inherited from SGML and HTML? Do you mean entity expansion attacks such as million laughs? HTML has only character rather than general entity references, and SGML has had the ENTLVL capacity to bound entity reference nesting since the year 1986. Edit: XML is just a proper subset of SGML by definition, hence it didn't introduce a single thing that wasn't there before. It only introduced XML-style empty elements and DTD-less markup, and SGML was extended in lockstep with XML to support these as well
- hyperman1 8y ago
  I'd consider user definable entities a problem, as you can't read a file without knowing the DTD. Million laughs is just a very ugly bonus. XML is more than the part inherited from SGML, it's also the XML culture surrounding it. Namespaces are an example of something that created an XML dialect. And of course SOAP, which actually needs the WS-I standard to explain what parts of the WS-* standards to use or ignore, and how to interprete them. And even then 2 WS-I stacks will rarely interop without trouble. Lets not blame SGML for that monstrosity
  - Mikhail_Edoshin 8y ago
    What's wrong with namespaces? These are simply globally unique identifiers that allow us to define and use our own globally unique names and make them passably human-readable. That is: <a:log /><b:log /><c:log /> can mean a math function, a text file that records what's happening, and a cut-off trunk of a tree and there will be no confusion whatsoever. (I really don't get how SOAP is relevant here.)

int_19h 8y ago

XML is verbose, and overcomplicated. But most purported replacements trimmed too much.

spiralx 8y ago

I would definitely use RelaxNG for specifying schemas instead of XSD - it's simpler both to read and write in every case I've tried, and the resulting schema is smaller as well, often by a lot. <element name="addressBook"> <zeroOrMore> <element name="card"> <attribute name="name"> <text/> </attribute> <attribute name="email"> <text/> </attribute> </element> </zeroOrMore> </element> http://www.relaxng.org/tutorial-20011203.html http://www.relaxng.org/tutorial-20011203.html Plus there's a non-XML "compressed" version as well: element addressBook { element card { element name { text }, element email { text } }+ } But I agree that XML like you posted is nasty, it's no harder to write <parameter name="ApplicationName">WhizBang</parameter> instead if you need generic parameters, or <ApplicationName>WhizBang</ApplicationName> if not.