7 ms·

This might be throwing a lit match into a gasoline refinery, but why not opt for XML in some circumstances? Between its strong schema and wsdl support for inte

This might be throwing a lit match into a gasoline refinery, but why not opt for XML in some circumstances? Between its strong schema and wsdl support for internet standards like soap web services, XML covers a lot of ground that Json encoding doesn't necessarily have without add-ons. I say this knowing this is an unfashionable opinion and XML has its own weaknesses, but in the spirit of using web standards and LoC approved "archivable formats", IMO there is still a place for XML in many serialization strategies around the computing landscape. Json is perfect for serializing between client and server operations or in progressive web apps running in JavaScript. It is quite serviceable in other places as well such as microservice REST APIs, but in other areas of the landscape like middleware, database record excerpts, desktop settings, data transfer files, Json is not much better or sometimes even slightly worse than XML.

deleted 7y ago
[deleted]
hombre_fatal 7y ago
Not the best context to suggest XML superiority: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_... If parsing JSON is bad, XML is a clusterfuck.
- Nicksil 7y ago
  > Not the best context to suggest XML superiority where was it insinuated XML is superior? It was a very reasonable response.
  - deleted 7y ago
    [deleted]
  - kelnos 7y ago
    There'd be no reason to suggest it as an alternative were it not for an opinion that it's superior.
    - brightball 7y ago
      It’s got a lot built around it that JSON doesn’t have an equivalent for. I still miss XSD and WSDL for a lot of cases. Other cases it was serious overkill where JSON is a better option. XML isn’t superior. It’s heavier but more complete. JSON is lighter and less complete. Everything in code is always about trade offs. The error comes when people advocate for one solution all the time.
      - beatgammit 7y ago
        If you're going to reach for automation, why not just use a binary format like protocol buffers, flat buffers, capn proto, etc? You get the tooling and a ton of performance for free. JSON is great because you don't need tooling. XML is great because it's expressive. You don't need expressiveness for a data format, but it works great as a markup language.
AtlasBarfed 7y ago
XML cannot be parsed into nested maps/dictionaries/lists/arrays without guidance from a type or a restricted xml structure. JSON can do that. It also maps pretty seamlessly to types/classes in most languages without annotations, attributes, or other serialization guides. It also has explicit indicators for lists vs subdocuments vs values for keys, which xml does not. XML tags can repeat, can have subtags, and then there are tag attributes. A JSON document can also be a list, while XML documents must be a tree with a root document. XML may be acceptable for documents. But seeing as how XHTML was a complete dud, I doubt it is useful even for that. And we didn't even need to get into the needless complexity of validation, namespaces, and other junk.
- crispyambulance 7y ago
  XML is a perfectly serviceable data exchange format. The parsers and serializers work great when used properly. It's nice to have schema. But I think people just got sick of XML because it was abused so badly with "web services", SOAP, wsdl and all those horrible technologies from the early naughts. Over-complicated balls of mud that made people miserable.
  - eknkc 7y ago
    Apple's plist format might be the weirdest abuse of XML as far as I can tell. The SOAP envelopes and shit like that were horrible but plist is plain weird. Everyone abused XML some way or another. JSON is not that "abusable" I'd say.
    - amaccuish 7y ago
      PLIST is pretty flexible though, the underlying storage can be XML, binary or even JSON now.
      - cellularmitosis 7y ago
        Implementing a binary plist encoding on you REST endpoints is actually pretty great for iOS devices.
legulere 7y ago
If JSON with its relative simplicity is already too complex and leading to a mine field, then XML is even worse by far.
specialist 7y ago
Syntax aside, I think the original mistake is IDLs, schemas, and other attempts at formalism. WSDL, SOAP, and all their precursors were attempted in spite of Postel's Law. Repeating myself: Back when I was doing electronic medical records, my two-person team ran circles around our (much larger) partners by abandoning the schema tool stack. We were able to detect, debug, correct interchange problems and deploy fixes in near realtime. Whereas our partners would take days. Just "screen scrap" inbound messages, use templates to generate outbound messages. I'd dummy up working payloads using tools like SoapUI. Convert those known good "reference" payloads into templates. (At the time, I preferred Velocity.) Version every thing. To troubleshoot, rerun the reference messages, diff the captured results. Massage until working. Our partners, and everyone I've told since, just couldn't grok this approach. No, no, no, we need schemas, code generators, etc. There's a separate HN post about Square using DSLs to implement OpenAPI endpoints. That's maybe 1/4th of the way to our own home made solution.
carapace 7y ago
Not to mention XSLT.
taftster 7y ago
One of the biggest advantages for XML are attributes and namespaces. I miss these in JSON. As AtlasBarfed mentioned, JSON has a native map and list structure in its syntax, which is sorely missed in XML. You have to rely on an XML Schema to know that some tag is expected to represent a map or list. JSON with attributes and namespaces would be my ideal world.
- beatgammit 7y ago
  Why do you want those? Attributes and namespaces just make in memory representation complicated. They're quite useful for markup, but I don't really know why you'd want them in a data format. Use JSON or a binary protocol for data, XML for markup.
twblalock 7y ago
XML manages to be difficult and complex for both computers and people to read. That's why it fell out of favor.
- dwaite 7y ago
  To be fair, there were a lot of very good ideas for a 2.x XML that solved a lot of the complexity. The problem was that none of the tools would be upgraded to support it. You'd basically have to create a new independent format to have proper compatibility once you introduce breaking changes.
  - dwaite 7y ago
    FWIW, the common changes were to - remove DTDs completely. - by removing DTDs, remove non-standard entities - by removing DTDs, remove the concepts of notations and all external resource resolution from the core spec. Also, no possibility of entity-expansion attacks. - by removing DTDs, remove validation from the core spec. - merge namespaces into the core specification. At the same time, make them mandatory - merge the concept of qualified names into the core specification - by making namespaces mandatory, all the variations of how namespaces get exposed can be eliminated - merge the info-set definition into the core specification - by describing XML items and how they relate, implementations can understand what data is relevant at a particular point while parsing the document. - Merge xml:id into the core specification. You also had some other fun outlier concepts: - Eliminate prefixes from infoset. This is mostly a breaking change for XPath and XML Schema. - Add an explicit qualified name token (possibly recycling the entity declaration). This would allow the above specs to have their functionality restored, although likely with a new format. - Accept qualified names without prefixes, such as via a {uri}:{localName} syntax.
Zarel 7y ago
I personally like XML a lot for rich text (I like HTML better than TeX) and layout (like in JSX for React), and it's not horrible if you want a readable representation for a tree, but I can't imagine using it for any other purpose. JSON is exactly designed for object serialization. XML can be used for that purpose but it's awkward and requires a lot of unnecessary decisions (what becomes a tag? what becomes an attribute? how do you represent null separately from the empty string?) which just have an easy answer in JSON. And I can't think of any advantage XML has to make up for that flaw. Sure, XML can have schemas, but so can JSON. I will agree that JSON is horrible for config files for humans to edit, but XML is quite possibly even worse at that. I don't really like YAML, either. TOML isn't bad, but I actually rather like JSON5 for config files - it's very readable for everyone who can read JSON, and fixes all the design decisions making it hard for humans to read and edit.

deleted 7y ago

[deleted]

hombre_fatal 7y ago

Not the best context to suggest XML superiority: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_... If parsing JSON is bad, XML is a clusterfuck.

Nicksil 7y ago
> Not the best context to suggest XML superiority where was it insinuated XML is superior? It was a very reasonable response.
- deleted 7y ago
  [deleted]
- kelnos 7y ago
  There'd be no reason to suggest it as an alternative were it not for an opinion that it's superior.
  - brightball 7y ago
    It’s got a lot built around it that JSON doesn’t have an equivalent for. I still miss XSD and WSDL for a lot of cases. Other cases it was serious overkill where JSON is a better option. XML isn’t superior. It’s heavier but more complete. JSON is lighter and less complete. Everything in code is always about trade offs. The error comes when people advocate for one solution all the time.
    - beatgammit 7y ago
      If you're going to reach for automation, why not just use a binary format like protocol buffers, flat buffers, capn proto, etc? You get the tooling and a ton of performance for free. JSON is great because you don't need tooling. XML is great because it's expressive. You don't need expressiveness for a data format, but it works great as a markup language.

AtlasBarfed 7y ago

XML cannot be parsed into nested maps/dictionaries/lists/arrays without guidance from a type or a restricted xml structure. JSON can do that. It also maps pretty seamlessly to types/classes in most languages without annotations, attributes, or other serialization guides. It also has explicit indicators for lists vs subdocuments vs values for keys, which xml does not. XML tags can repeat, can have subtags, and then there are tag attributes. A JSON document can also be a list, while XML documents must be a tree with a root document. XML may be acceptable for documents. But seeing as how XHTML was a complete dud, I doubt it is useful even for that. And we didn't even need to get into the needless complexity of validation, namespaces, and other junk.

crispyambulance 7y ago
XML is a perfectly serviceable data exchange format. The parsers and serializers work great when used properly. It's nice to have schema. But I think people just got sick of XML because it was abused so badly with "web services", SOAP, wsdl and all those horrible technologies from the early naughts. Over-complicated balls of mud that made people miserable.
- eknkc 7y ago
  Apple's plist format might be the weirdest abuse of XML as far as I can tell. The SOAP envelopes and shit like that were horrible but plist is plain weird. Everyone abused XML some way or another. JSON is not that "abusable" I'd say.
  - amaccuish 7y ago
    PLIST is pretty flexible though, the underlying storage can be XML, binary or even JSON now.
    - cellularmitosis 7y ago
      Implementing a binary plist encoding on you REST endpoints is actually pretty great for iOS devices.

legulere 7y ago

If JSON with its relative simplicity is already too complex and leading to a mine field, then XML is even worse by far.

specialist 7y ago

Syntax aside, I think the original mistake is IDLs, schemas, and other attempts at formalism. WSDL, SOAP, and all their precursors were attempted in spite of Postel's Law. Repeating myself: Back when I was doing electronic medical records, my two-person team ran circles around our (much larger) partners by abandoning the schema tool stack. We were able to detect, debug, correct interchange problems and deploy fixes in near realtime. Whereas our partners would take days. Just "screen scrap" inbound messages, use templates to generate outbound messages. I'd dummy up working payloads using tools like SoapUI. Convert those known good "reference" payloads into templates. (At the time, I preferred Velocity.) Version every thing. To troubleshoot, rerun the reference messages, diff the captured results. Massage until working. Our partners, and everyone I've told since, just couldn't grok this approach. No, no, no, we need schemas, code generators, etc. There's a separate HN post about Square using DSLs to implement OpenAPI endpoints. That's maybe 1/4th of the way to our own home made solution.

carapace 7y ago

Not to mention XSLT.

taftster 7y ago

One of the biggest advantages for XML are attributes and namespaces. I miss these in JSON. As AtlasBarfed mentioned, JSON has a native map and list structure in its syntax, which is sorely missed in XML. You have to rely on an XML Schema to know that some tag is expected to represent a map or list. JSON with attributes and namespaces would be my ideal world.

beatgammit 7y ago
Why do you want those? Attributes and namespaces just make in memory representation complicated. They're quite useful for markup, but I don't really know why you'd want them in a data format. Use JSON or a binary protocol for data, XML for markup.

twblalock 7y ago

XML manages to be difficult and complex for both computers and people to read. That's why it fell out of favor.

dwaite 7y ago
To be fair, there were a lot of very good ideas for a 2.x XML that solved a lot of the complexity. The problem was that none of the tools would be upgraded to support it. You'd basically have to create a new independent format to have proper compatibility once you introduce breaking changes.
- dwaite 7y ago
  FWIW, the common changes were to - remove DTDs completely. - by removing DTDs, remove non-standard entities - by removing DTDs, remove the concepts of notations and all external resource resolution from the core spec. Also, no possibility of entity-expansion attacks. - by removing DTDs, remove validation from the core spec. - merge namespaces into the core specification. At the same time, make them mandatory - merge the concept of qualified names into the core specification - by making namespaces mandatory, all the variations of how namespaces get exposed can be eliminated - merge the info-set definition into the core specification - by describing XML items and how they relate, implementations can understand what data is relevant at a particular point while parsing the document. - Merge xml:id into the core specification. You also had some other fun outlier concepts: - Eliminate prefixes from infoset. This is mostly a breaking change for XPath and XML Schema. - Add an explicit qualified name token (possibly recycling the entity declaration). This would allow the above specs to have their functionality restored, although likely with a new format. - Accept qualified names without prefixes, such as via a {uri}:{localName} syntax.

Zarel 7y ago

I personally like XML a lot for rich text (I like HTML better than TeX) and layout (like in JSX for React), and it's not horrible if you want a readable representation for a tree, but I can't imagine using it for any other purpose. JSON is exactly designed for object serialization. XML can be used for that purpose but it's awkward and requires a lot of unnecessary decisions (what becomes a tag? what becomes an attribute? how do you represent null separately from the empty string?) which just have an easy answer in JSON. And I can't think of any advantage XML has to make up for that flaw. Sure, XML can have schemas, but so can JSON. I will agree that JSON is horrible for config files for humans to edit, but XML is quite possibly even worse at that. I don't really like YAML, either. TOML isn't bad, but I actually rather like JSON5 for config files - it's very readable for everyone who can read JSON, and fixes all the design decisions making it hard for humans to read and edit.