6 ms·

It is interesting that people love json (now with schema), but hate XML while loving HTML at the same time. It is all pretty boring and largely the same imo.

zdragnar 3y ago
The absolute worst bit of XML is the confused implementations. What should be an attribute on a tag, and what should go between tags? Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently: <some>true</some> versus <some>1</some> Some systems require the token "true", others will only treat 1 as the boolean true. For example, MS claims that for exchange ASD boolean values must be integer 1 or 0 [0], but then links to a W3C spec that allows for the tokens true and false [1] At least with JSON and HTML, you don't need a separate definition file for basic, primitive data types. [0] https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-asdtype/dceb8d02-55dc-427a-8d66-8bbf08f4dc26 https://learn.microsoft.com/en-us/openspecs/exchange_server_... [1] https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#boolean https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#boolean
- berkes 3y ago
  How is your example any better in JSON? { some: true, someOther: 1, another: "true" }
  - likis 3y ago
    Only the first one will be treated as a boolean in JSON. The second one is a number, and the third is a string.
    - crabbone 3y ago
      > The second one is a number This would've been useful if you knew what kind of number it was... As for what goes into separate elements and what goes into attributes: a typical answer to this is that simple types (as per XSL) go into attributes, complex types go into elements. Compare this to JSON's screwed-up definition of "hash-tables" (the things in curly braces) which doesn't require that "keys" be unique. XML wasn't perfect. But JSON isn't really better. It sucks in a slightly different way because people keep inventing these formats w/o much thinking, and once discover problems, don't fix them.
      - adamlett 3y ago
        This would've been useful if you knew what kind of number it was... JSON isn’t ambiguous when it comes to this. Numbers are arbitrary precision decimal numbers[1]. I’m guessing your issue is with how Javascript interprets JSON numbers as 32 bit floats. But that is a (mis-)feature of JavaScript and switching your serialization format to XML would not help, because JavaScript represents all numbers as 32-bit floats. [1] https://www.json.org/json-en.html https://www.json.org/json-en.html
    - danbruc 3y ago
      Well, it's the same in XML, more or less. [1] The difference is that XML cleanly separates types and data, all the type information is in the schema and there is no type information in the data, so without a schema you can not properly type the data. JSON on the other hand does not separate types and data, the types are implicitly contained in the data. So you can get type information from the data without a schema, at least up to the point where JSON's simple type system is no longer expressive enough, then you need - just as with XML - a schema to get the correct type information, for example to distinguish actual strings from dates. If you really need this, nobody stops you from including type information in XMLs, <have type="boolean">true</have> attributes on elements or <quote>"strings"</quote> but not numbers <numbers>123</numbers> and use that. You will of course have to do this on your own, that is just not the way XML is supposed to be used. [1] Let me clarify this a bit. If you handle XML, you usually have a schema and therefore the type information. If you have a non-trivial JSON, you also need a schema for the types. You can only get away without a schema for simple JSONs where the implicit type information is good enough. But then you could do almost the same with XML, just parse the content and see like what type it looks. You will not get quite to what JSON can do in a sane way but it might be good enough just as JSON without a schema is sometimes good enough.
      - berkes 3y ago
        > a schema to get the correct type information, for example to distinguish actual strings from dates. Which, in practice, is a terrible oversight. I've honestly never seen a JSON store/transport/serde in practice without dates and/or times in them. There's always some updated_at or captured_on somewhere in the API or dataset. Of all the data-types needed, I'd say dates are amongst the most important. At least more important in practice than floats; which JSON does support for odd reasons. Especially with dates being ambigous at best and inconsistent at worst. Pubquiz: when was/or will be, how much paid? { currency: "THB", paid_at: "04-03-2566", amount: 13.37 }¹ - JSON is neat for simple use-cases, but utterly impractical for when precision and correctness is required. Yet here we are, building around and on top of it, to get that correctness and precision. ¹I'm messing a bit, 'cause this calendar isn't used in practice for such use-cases anymore. Hardly. But I've seen this with Hijri calendars. And those silly US date-formats. I've seen it "solved" with complex structs like { created_at: { year: 2022, day: ... , timezone:xxx}". I've myself "fixed" floating-point precision issues in financial applications that used JSON by using all-strings: "{ currency: "USD", amount_in_cents: "1337" } and such.
    - peoplefromibiza 3y ago
      > The second one is a number You mean a float, right?
      - k__ 3y ago
        A double-precision 64-bit binary format IEEE 754, if you will!
        peoplefromibiza 3y ago
        fun fact: that's JavaScript. JavaScript only supports double-precision 64-bit binary format IEEE 754. But JSON doesn't disallow arbitrary precision numbers, that's up to the parser implementation. number integer fraction exponent In fact not all implementations support IEEE 754 doubles, and, from my experience, when dealing with money and rounding errors, many decide to serialize numbers as exact strings and use custom code for deserialization.
        berkes 3y ago
        > when dealing with money and rounding errors, many decide to serialize numbers as exact strings and use custom code for deserialization That's exactly what I'm doing. And indeed another reason why I feel embarrassed by JSON. I mean, we -the industry- have been doing financial data transport over computer networks, for how long now? fifty years? And we keep "inventing" transport formats that unsolve issues that have long been solved and done. XML had this solved[1]. Hell, even the ancient MT940[2] had this solved. [1] https://web.archive.org/web/20200618100100/https://deutschebank.nl/nl/docs/MT94042_EN.pdf https://web.archive.org/web/20200618100100/https://deutscheb... (pdf warning) [2] e.g. https://financialdataexchange.org/FDX/About/OFX-Work-Group.aspx?WebsiteKey=deae9d6d-1a7a-457b-a678-8a5517f8a474&a315d1c24e44=3#a315d1c24e44 https://financialdataexchange.org/FDX/About/OFX-Work-Group.a...
- pbourke 3y ago
  XML is only concerned with whether a document is well-formed, not its conformity to a given schema. Schemas like XSD, DTD, etc can be plugged in later. Many systems just have an ad hoc schema. > At least with JSON and HTML, you don't need a separate definition file for basic, primitive data types. Unless I’m missing your meaning, this seems like an apples-to-oranges comparison. HTML is not a general-purpose format like JSON. It’s a very complicated document format that is validated with reference to an external spec. I think XML is a great fit for a document format that can become arbitrarily complex yet still easy to author and validate. It’s obviously a really poor fit for a wire transport protocol.
  - osigurdson 3y ago
    I don't see XML and json as different at all - they are both markup languages that describe trees. As long as what you are describing is a tree, either is fine. Of course, I would never do an XML endpoint on a rest http service since no one would expect that and they would assume that you don't know what you are doing and your service sucks.
- peoplefromibiza 3y ago
  > you don't need a separate definition file for basic, primitive data types. unless you need something different from JavaScript primitive data types. For example integers. Or null means nothing to you. Or you want a faithful representation of input Welcome to Node.js v20.5.1. Type ".help" for more information. > JSON.stringify(undefined) undefined > JSON.stringify([undefined]) '[null]' but then jq "." <<< "[null]" [ null ] jq "." <<< "undefined" parse error: Invalid numeric literal at line 2, column 0
  - darrenf 3y ago
    I'm not certain I understand the point you're trying to make regarding `undefined`, or indeed the expectation that `jq` and `JSON.stringify()` follow the same rules. `JSON.stringify()` is documented to behave exactly as you demonstrate, so there's no surprises: undefined, Function, and Symbol values are not valid JSON values. If any such values are encountered during conversion, they are either omitted (when found in an object) or changed to null (when found in an array). JSON.stringify() can return undefined when passing in "pure" values like JSON.stringify(() => {}) or JSON.stringify(undefined). Expecting `jq` to somehow understand that its input came from Javascript's `JSON.stringify()` and so should be parsed on that basis seems ... odd? I don't see any problem with what `jq` is doing there, but anyway I don't see a problem with JSON itself in these examples.
    - peoplefromibiza 3y ago
      > undefined, Function, and Symbol values are not valid JSON values that's the point. The official JSON serializer from every broswer vendor and every Node installation produce invalid JSON. Which for the JavaScriptObjectNotation is kinda hilarious. > Expecting `jq` to somehow understand that its input came from Javascript's `JSON.stringify()` I would expect `JSON.stringify` to give an error if trying to serialize something that naturally does not map to JSON, like many other libraries do. You have to provide a manual override for those situations. But JavaScript and ECMA (`JSON.stringify` is defined in the standard) decided that no, they can ignore the specs for some reason. Problem is they can't fix it now, because too many applications rely on those wrong assumptions. Here it is the reason why you can find <flag>true</flag> and <flag>1</flag> Difference being XML was born to standardize the document format, JSON aspired to be a data format but failed miserably at it, even at the most basic level, like saying an int from a float. The spec is simply too vague and ambiguous to give some guarantee of interoperability, beyond numbers and strings. Maybe we should all switch to MessagePack
- dwaite 3y ago
  > The absolute worst bit of XML is the confused implementations. What should be an attribute on a tag, and what should go between tags? XML is a language for marking up text. SVG uses attributes for all vector data, because the vector points are not meant to be presented to a user as raw data. If I embed a SVG into a XHTML document and the browser does not understand SVG, the text within the graphic is still presented to the user. > Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently: This is not a responsibility of XML, which deals in a common well-formed markup format for various document format. It sounds like you are dealing with a tool that has defined an XML-based data interchange format, and that they may have inconsistent tooling for their format.
- euroderf 3y ago
  > What should be an attribute on a tag, and what should go between tags? I think a good rule of thumb is that attributes are for key/value pairs that are probably not user-visible and definitely not directly user-editable. Carried to a logical conclusion, this would simplify the auto-creation of form GUIs.
- osigurdson 3y ago
  >> What should be an attribute on a tag, and what should go between tags? Are you ok with <a href="..">link</a>? That was kind of my original point, people are fine with html but don't like XML. I think the real reason people don't like XML is it reminds them of Steve Ballmer.
fauigerzigerk 3y ago
JSON is far simpler because it has no namespaces and no entities. But I think complexity is always 90% culture. It's pretty arbitrary what kind of culture grows around a particular technology.
- HdS84 3y ago
  Yeah, culture is a big one. See dotnet vs java. The latter picked up many of c# feature over the years but is still much more verbose, e.g. because their developers still abhor var
  - brabel 3y ago
    Hey, I work with Java, at work no one has ever complained about a var. Must be your inner circle only?
    - HdS84 3y ago
      Quite possibly. We would need to look through a few OSs projects to determine what's a common style.
- crabbone 3y ago
  There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far from simple in that later case. I.e. learning about namespaces would take a programmer couple of hours, including a foosball match and a coffee break, but working around JSONs bad decisions when it comes to number serialization or sequence serialization will probably take days in the best case, with a side-effect that this work will most likely have to be done on an existing product after a customer complained about corrupting or losing their data...
  - geysersam 3y ago
HdS84 3y ago
XML suffers from too many options and useless bells and whistles. E.g. the attribute vs Parameter topic is a source of confusion, without adding much value, especially if the source and target are object oriented and/ or a relational db. What's the point? Then there are namespaces, sure there are probably lots of places where you need to use them. But I never encountered a place where they are really needed, but because they are the default you need to work with them or your queries do not work. Super confusing for beginners and annoying as heck.
- crabbone 3y ago
  Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? So what if it's hard? -- Spend an hour with the reference document, and your problems will go away. In the days when XML was popular I've been more active in several Web forums that helped novice users with particular technology (and that included XML). Not a single confusion about XML namespaces came from someone who read the reference. Quoting the reference would be also a very efficient way to clear the confusion. Bottom line: it's not a problem worth mentioning. In the grand scheme of things an hour you'd have to spend reading the specification is a drop in a bucket compared to all the time you'd have to work with XML. It's a fixed-size effort that you have make once. Compare this to having to deal with bad "number" serialization that you have to deal in JSON every time in a new program that deals with JSON.
  - toomim 3y ago
    > Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? Two reasons: 1) Because it's unnecessary complexity. When you add unnecessary complexity into fundamental technology that everything uses, you've now made everything worse. It's like polluting the lake, and then ignoring the fact that beginners need to learn how to boil the water properly drinking it. 2) Because that prevents the technology from being adopted. Whether you think it's justified or not, beginners will choose the tech that's easier to use, and it will succeed. The market of technology adoption forces us to make things simple for beginners, and in the end, that's good for all of us.
slaymaker1907 3y ago
JSON is a much better serialization format since XML was designed as a document format. For example, there is no standardized way to serialize a string with a null character even if you escape it (this is allowed in many programming languages). JSON just says do “\0” and calls it a day. I’m not sure if it’s better for users, but it’s certainly easier to work with as a dev. HTML isn’t trying to serialize abstract data and is doing what XML does best in being a document/GUI format. It doesn’t matter all that much that it can’t represent null characters in a standard way because it isn’t a printable character.
- crabbone 3y ago
  Try using UTF-8 encoding for XML, and your problems with zero byte encoding will go away. Your understanding of "easier" is oversimplified to the point that it's wrong. It's easier to do the wrong thing in JSON, it's harder to do the right thing in JSON (compared to XML). JSON is a poorly thought-out format. It's problems become progressively more difficult to deal with the more you expect of your program.
  - unilynx 3y ago
    JSON and XML both support UTF-8. Neither supports embedding arbitrary binary data directly, especially if that data is not valid in your current character set
    - crabbone 3y ago
      You wanted to send zero byte. This is how you send zero byte. You are making unrelated claims now that has nothing to do with your original claim.
      - unilynx 3y ago
        You can't safely send zero bytes over XML even with UTF-8 encoding. Not in practice: echo '<zero></zero>' | xmllint - -:1: parser error : xmlParseCharRef: invalid xmlChar value 0 <zero></zero> ^ printf '<?xml version="1.0" encoding="utf-8"?><zero>\0</zero>' | xmllint - -:1: parser error : Premature end of data in tag zero line 1 <?xml version="1.0" encoding="utf-8"?><zero> ^ And not in theory: https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-formed https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-form... Character Range [2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ [2a] RestrictedChar ::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F]
geysersam 3y ago
It's very easy to understand why people prefer JSON. 95% of developers know exactly what JSON is without ever having read anything technical about it. It's obvious. XML on the other hand... Who here can say they actually know anything substantial about XML besides the syntax? My guess is <10%.
- deleted 3y ago
  [deleted]
revskill 3y ago
Look, with JSX you can put anything as props. JSON is just pure data.
throwawaymaths 3y ago
Which is better xml design for a pure data payload (not textual content)? <foo>something</foo> Or <foo value="something"/> When you get back with a coherent universal argument, we'll revisit the json vs xml question.
- lenkite 3y ago
  Isn't this very easy ? Short, Succinct and a Simple No-frills string ? Put it in the attribute. Big, Long and Arbitrary Length Data ? Put it in the content of the element. Now gimme money.
- Devasta 3y ago
  If these are the sort of questions that are tripping you up, just use <foo>something</foo> for everything.

zdragnar 3y ago

The absolute worst bit of XML is the confused implementations. What should be an attribute on a tag, and what should go between tags? Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently: <some>true</some> versus <some>1</some> Some systems require the token "true", others will only treat 1 as the boolean true. For example, MS claims that for exchange ASD boolean values must be integer 1 or 0 [0], but then links to a W3C spec that allows for the tokens true and false [1] At least with JSON and HTML, you don't need a separate definition file for basic, primitive data types. [0] https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-asdtype/dceb8d02-55dc-427a-8d66-8bbf08f4dc26 https://learn.microsoft.com/en-us/openspecs/exchange_server_... [1] https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#boolean https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#boolean

berkes 3y ago
How is your example any better in JSON? { some: true, someOther: 1, another: "true" }
- likis 3y ago
  Only the first one will be treated as a boolean in JSON. The second one is a number, and the third is a string.
  - crabbone 3y ago
    > The second one is a number This would've been useful if you knew what kind of number it was... As for what goes into separate elements and what goes into attributes: a typical answer to this is that simple types (as per XSL) go into attributes, complex types go into elements. Compare this to JSON's screwed-up definition of "hash-tables" (the things in curly braces) which doesn't require that "keys" be unique. XML wasn't perfect. But JSON isn't really better. It sucks in a slightly different way because people keep inventing these formats w/o much thinking, and once discover problems, don't fix them.
    - adamlett 3y ago
      This would've been useful if you knew what kind of number it was... JSON isn’t ambiguous when it comes to this. Numbers are arbitrary precision decimal numbers[1]. I’m guessing your issue is with how Javascript interprets JSON numbers as 32 bit floats. But that is a (mis-)feature of JavaScript and switching your serialization format to XML would not help, because JavaScript represents all numbers as 32-bit floats. [1] https://www.json.org/json-en.html https://www.json.org/json-en.html
  - danbruc 3y ago
    Well, it's the same in XML, more or less. [1] The difference is that XML cleanly separates types and data, all the type information is in the schema and there is no type information in the data, so without a schema you can not properly type the data. JSON on the other hand does not separate types and data, the types are implicitly contained in the data. So you can get type information from the data without a schema, at least up to the point where JSON's simple type system is no longer expressive enough, then you need - just as with XML - a schema to get the correct type information, for example to distinguish actual strings from dates. If you really need this, nobody stops you from including type information in XMLs, <have type="boolean">true</have> attributes on elements or <quote>"strings"</quote> but not numbers <numbers>123</numbers> and use that. You will of course have to do this on your own, that is just not the way XML is supposed to be used. [1] Let me clarify this a bit. If you handle XML, you usually have a schema and therefore the type information. If you have a non-trivial JSON, you also need a schema for the types. You can only get away without a schema for simple JSONs where the implicit type information is good enough. But then you could do almost the same with XML, just parse the content and see like what type it looks. You will not get quite to what JSON can do in a sane way but it might be good enough just as JSON without a schema is sometimes good enough.
    - berkes 3y ago
      > a schema to get the correct type information, for example to distinguish actual strings from dates. Which, in practice, is a terrible oversight. I've honestly never seen a JSON store/transport/serde in practice without dates and/or times in them. There's always some updated_at or captured_on somewhere in the API or dataset. Of all the data-types needed, I'd say dates are amongst the most important. At least more important in practice than floats; which JSON does support for odd reasons. Especially with dates being ambigous at best and inconsistent at worst. Pubquiz: when was/or will be, how much paid? { currency: "THB", paid_at: "04-03-2566", amount: 13.37 }¹ - JSON is neat for simple use-cases, but utterly impractical for when precision and correctness is required. Yet here we are, building around and on top of it, to get that correctness and precision. ¹I'm messing a bit, 'cause this calendar isn't used in practice for such use-cases anymore. Hardly. But I've seen this with Hijri calendars. And those silly US date-formats. I've seen it "solved" with complex structs like { created_at: { year: 2022, day: ... , timezone:xxx}". I've myself "fixed" floating-point precision issues in financial applications that used JSON by using all-strings: "{ currency: "USD", amount_in_cents: "1337" } and such.
  - peoplefromibiza 3y ago
    > The second one is a number You mean a float, right?
    - k__ 3y ago
      A double-precision 64-bit binary format IEEE 754, if you will!
      - peoplefromibiza 3y ago
        fun fact: that's JavaScript. JavaScript only supports double-precision 64-bit binary format IEEE 754. But JSON doesn't disallow arbitrary precision numbers, that's up to the parser implementation. number integer fraction exponent In fact not all implementations support IEEE 754 doubles, and, from my experience, when dealing with money and rounding errors, many decide to serialize numbers as exact strings and use custom code for deserialization.
        berkes 3y ago
        > when dealing with money and rounding errors, many decide to serialize numbers as exact strings and use custom code for deserialization That's exactly what I'm doing. And indeed another reason why I feel embarrassed by JSON. I mean, we -the industry- have been doing financial data transport over computer networks, for how long now? fifty years? And we keep "inventing" transport formats that unsolve issues that have long been solved and done. XML had this solved[1]. Hell, even the ancient MT940[2] had this solved. [1] https://web.archive.org/web/20200618100100/https://deutschebank.nl/nl/docs/MT94042_EN.pdf https://web.archive.org/web/20200618100100/https://deutscheb... (pdf warning) [2] e.g. https://financialdataexchange.org/FDX/About/OFX-Work-Group.aspx?WebsiteKey=deae9d6d-1a7a-457b-a678-8a5517f8a474&a315d1c24e44=3#a315d1c24e44 https://financialdataexchange.org/FDX/About/OFX-Work-Group.a...
pbourke 3y ago
XML is only concerned with whether a document is well-formed, not its conformity to a given schema. Schemas like XSD, DTD, etc can be plugged in later. Many systems just have an ad hoc schema. > At least with JSON and HTML, you don't need a separate definition file for basic, primitive data types. Unless I’m missing your meaning, this seems like an apples-to-oranges comparison. HTML is not a general-purpose format like JSON. It’s a very complicated document format that is validated with reference to an external spec. I think XML is a great fit for a document format that can become arbitrarily complex yet still easy to author and validate. It’s obviously a really poor fit for a wire transport protocol.
- osigurdson 3y ago
  I don't see XML and json as different at all - they are both markup languages that describe trees. As long as what you are describing is a tree, either is fine. Of course, I would never do an XML endpoint on a rest http service since no one would expect that and they would assume that you don't know what you are doing and your service sucks.
peoplefromibiza 3y ago
> you don't need a separate definition file for basic, primitive data types. unless you need something different from JavaScript primitive data types. For example integers. Or null means nothing to you. Or you want a faithful representation of input Welcome to Node.js v20.5.1. Type ".help" for more information. > JSON.stringify(undefined) undefined > JSON.stringify([undefined]) '[null]' but then jq "." <<< "[null]" [ null ] jq "." <<< "undefined" parse error: Invalid numeric literal at line 2, column 0
- darrenf 3y ago
  I'm not certain I understand the point you're trying to make regarding `undefined`, or indeed the expectation that `jq` and `JSON.stringify()` follow the same rules. `JSON.stringify()` is documented to behave exactly as you demonstrate, so there's no surprises: undefined, Function, and Symbol values are not valid JSON values. If any such values are encountered during conversion, they are either omitted (when found in an object) or changed to null (when found in an array). JSON.stringify() can return undefined when passing in "pure" values like JSON.stringify(() => {}) or JSON.stringify(undefined). Expecting `jq` to somehow understand that its input came from Javascript's `JSON.stringify()` and so should be parsed on that basis seems ... odd? I don't see any problem with what `jq` is doing there, but anyway I don't see a problem with JSON itself in these examples.
  - peoplefromibiza 3y ago
    > undefined, Function, and Symbol values are not valid JSON values that's the point. The official JSON serializer from every broswer vendor and every Node installation produce invalid JSON. Which for the JavaScriptObjectNotation is kinda hilarious. > Expecting `jq` to somehow understand that its input came from Javascript's `JSON.stringify()` I would expect `JSON.stringify` to give an error if trying to serialize something that naturally does not map to JSON, like many other libraries do. You have to provide a manual override for those situations. But JavaScript and ECMA (`JSON.stringify` is defined in the standard) decided that no, they can ignore the specs for some reason. Problem is they can't fix it now, because too many applications rely on those wrong assumptions. Here it is the reason why you can find <flag>true</flag> and <flag>1</flag> Difference being XML was born to standardize the document format, JSON aspired to be a data format but failed miserably at it, even at the most basic level, like saying an int from a float. The spec is simply too vague and ambiguous to give some guarantee of interoperability, beyond numbers and strings. Maybe we should all switch to MessagePack
dwaite 3y ago
> The absolute worst bit of XML is the confused implementations. What should be an attribute on a tag, and what should go between tags? XML is a language for marking up text. SVG uses attributes for all vector data, because the vector points are not meant to be presented to a user as raw data. If I embed a SVG into a XHTML document and the browser does not understand SVG, the text within the graphic is still presented to the user. > Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently: This is not a responsibility of XML, which deals in a common well-formed markup format for various document format. It sounds like you are dealing with a tool that has defined an XML-based data interchange format, and that they may have inconsistent tooling for their format.
euroderf 3y ago
> What should be an attribute on a tag, and what should go between tags? I think a good rule of thumb is that attributes are for key/value pairs that are probably not user-visible and definitely not directly user-editable. Carried to a logical conclusion, this would simplify the auto-creation of form GUIs.
osigurdson 3y ago
>> What should be an attribute on a tag, and what should go between tags? Are you ok with <a href="..">link</a>? That was kind of my original point, people are fine with html but don't like XML. I think the real reason people don't like XML is it reminds them of Steve Ballmer.

fauigerzigerk 3y ago

JSON is far simpler because it has no namespaces and no entities. But I think complexity is always 90% culture. It's pretty arbitrary what kind of culture grows around a particular technology.

HdS84 3y ago
Yeah, culture is a big one. See dotnet vs java. The latter picked up many of c# feature over the years but is still much more verbose, e.g. because their developers still abhor var
- brabel 3y ago
  Hey, I work with Java, at work no one has ever complained about a var. Must be your inner circle only?
  - HdS84 3y ago
    Quite possibly. We would need to look through a few OSs projects to determine what's a common style.
crabbone 3y ago
There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far from simple in that later case. I.e. learning about namespaces would take a programmer couple of hours, including a foosball match and a coffee break, but working around JSONs bad decisions when it comes to number serialization or sequence serialization will probably take days in the best case, with a side-effect that this work will most likely have to be done on an existing product after a customer complained about corrupting or losing their data...
- geysersam 3y ago

HdS84 3y ago

XML suffers from too many options and useless bells and whistles. E.g. the attribute vs Parameter topic is a source of confusion, without adding much value, especially if the source and target are object oriented and/ or a relational db. What's the point? Then there are namespaces, sure there are probably lots of places where you need to use them. But I never encountered a place where they are really needed, but because they are the default you need to work with them or your queries do not work. Super confusing for beginners and annoying as heck.

crabbone 3y ago
Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? So what if it's hard? -- Spend an hour with the reference document, and your problems will go away. In the days when XML was popular I've been more active in several Web forums that helped novice users with particular technology (and that included XML). Not a single confusion about XML namespaces came from someone who read the reference. Quoting the reference would be also a very efficient way to clear the confusion. Bottom line: it's not a problem worth mentioning. In the grand scheme of things an hour you'd have to spend reading the specification is a drop in a bucket compared to all the time you'd have to work with XML. It's a fixed-size effort that you have make once. Compare this to having to deal with bad "number" serialization that you have to deal in JSON every time in a new program that deals with JSON.
- toomim 3y ago
  > Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? Two reasons: 1) Because it's unnecessary complexity. When you add unnecessary complexity into fundamental technology that everything uses, you've now made everything worse. It's like polluting the lake, and then ignoring the fact that beginners need to learn how to boil the water properly drinking it. 2) Because that prevents the technology from being adopted. Whether you think it's justified or not, beginners will choose the tech that's easier to use, and it will succeed. The market of technology adoption forces us to make things simple for beginners, and in the end, that's good for all of us.

slaymaker1907 3y ago

JSON is a much better serialization format since XML was designed as a document format. For example, there is no standardized way to serialize a string with a null character even if you escape it (this is allowed in many programming languages). JSON just says do “\0” and calls it a day. I’m not sure if it’s better for users, but it’s certainly easier to work with as a dev. HTML isn’t trying to serialize abstract data and is doing what XML does best in being a document/GUI format. It doesn’t matter all that much that it can’t represent null characters in a standard way because it isn’t a printable character.

crabbone 3y ago
Try using UTF-8 encoding for XML, and your problems with zero byte encoding will go away. Your understanding of "easier" is oversimplified to the point that it's wrong. It's easier to do the wrong thing in JSON, it's harder to do the right thing in JSON (compared to XML). JSON is a poorly thought-out format. It's problems become progressively more difficult to deal with the more you expect of your program.
- unilynx 3y ago
  JSON and XML both support UTF-8. Neither supports embedding arbitrary binary data directly, especially if that data is not valid in your current character set
  - crabbone 3y ago
    You wanted to send zero byte. This is how you send zero byte. You are making unrelated claims now that has nothing to do with your original claim.
    - unilynx 3y ago
      You can't safely send zero bytes over XML even with UTF-8 encoding. Not in practice: echo '<zero></zero>' | xmllint - -:1: parser error : xmlParseCharRef: invalid xmlChar value 0 <zero></zero> ^ printf '<?xml version="1.0" encoding="utf-8"?><zero>\0</zero>' | xmllint - -:1: parser error : Premature end of data in tag zero line 1 <?xml version="1.0" encoding="utf-8"?><zero> ^ And not in theory: https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-formed https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-form... Character Range [2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ [2a] RestrictedChar ::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F]

geysersam 3y ago

It's very easy to understand why people prefer JSON. 95% of developers know exactly what JSON is without ever having read anything technical about it. It's obvious. XML on the other hand... Who here can say they actually know anything substantial about XML besides the syntax? My guess is <10%.

deleted 3y ago
[deleted]

revskill 3y ago

Look, with JSX you can put anything as props. JSON is just pure data.

throwawaymaths 3y ago

Which is better xml design for a pure data payload (not textual content)? <foo>something</foo> Or <foo value="something"/> When you get back with a coherent universal argument, we'll revisit the json vs xml question.

lenkite 3y ago
Isn't this very easy ? Short, Succinct and a Simple No-frills string ? Put it in the attribute. Big, Long and Arbitrary Length Data ? Put it in the content of the element. Now gimme money.
Devasta 3y ago
If these are the sort of questions that are tripping you up, just use <foo>something</foo> for everything.