5 ms·

XML was supposed to be a silver bullet of the myriad of ad-hoc formats for structuring documents that existed in the wild pre 2000(I got this information contes

by lp4vn 4y ago

XML was supposed to be a silver bullet of the myriad of ad-hoc formats for structuring documents that existed in the wild pre 2000(I got this information contested here, but that's what an old professor told me). In the XML "stack" you can find the XSL to ensure the validity of an XML document, the XPath to be a querying language, the XSLT to be a language for writing transformations, etc. I think one must at least respect XML stack vision of coherence and completeness. Then you have things like JSON where the whole wheel is being reinvented, in my opinion, for no clear purpose. You have for instance hundreds of libraries for creating a JSON schema and everything looks like a waste of time overall. Before anyone asks me, yes I have used JSON and YAML and I never could really understand why people keep recreating basic stuff like markup languages instead of sticking to whatever is available. And yes, verbosity because of the XML tag system always sounded a pretty silly argument to me.

college_physics 4y ago
> for no clear purpose performance may have been one driver, though for the "API web" which is the main use case there are better performing options than json > everything looks like a waste of time overall maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate.
- lp4vn 4y ago
  >maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate. Agreed.
dtech 4y ago
The reason is pretty clear, XML and its ecosystem was (is) enormously complex. When naively - but correctly - parsing introduces serious security vulnerabilities [1] you kinda have problems as a format. XML is just incredibly hard to get correct, understand, and be performant. JSON from the get-go was very easy to understand and start with so it gained the upper hand. [1] https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://owasp.org/www-community/vulnerabilities/XML_External...
- deleted 4y ago
  [deleted]
- butlerm 4y ago
  I wouldn't consider that a parsing vulnerability - XML is relatively easy to parse - but rather an XML processing vulnerability, as in you must disable certain features (like arbitrary filesystem access) when processing an untrusted document. With hindsight, an XML processing library should require that you turn features like that on, rather than require that you turn them off. Opt in to dangerous features rather than opt out of them in other words.
tannhaeuser 4y ago
> that's what an old professor told me Well then your prof has no idea what (s)he's talking about I'm afraid. XML is just what the spec says on page 1 sentence 1 [1]: > The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. Where "generic SGML" refers to the property of XML being always fully tagged and not needing markup declarations, but still able to make use of those for validation and limited forms of entity expansion. Full SGML OTOH uses markup declarations for tag inference/omission (as in HTML), attribute short form canonicalization (also as in HTML), Wiki syntaxes (as in markdown), stylesheets (as in CSS), and other features such as type safe/injection free templating, processing pipelines/document "views" and as general extension mechanism. [1]: https://www.w3.org/TR/REC-xml/ https://www.w3.org/TR/REC-xml/
EdiX 4y ago
XML was a bad fit for almost everything people did with it. The natural data model of XML is alien to all programming languages people use: it is alien to scripting languages because you want hashmaps and lists and it is alien to static languages because you want structs and lists. So you usually ended up having to have a two stage parser, with the first stage turning XML into some kind of DOM and then your handrolled DOM-to-internal-representation thing. That's also most of the justification for XML's ecosystem: - You need XSD to make sure that your DOM-to-internal-representation code doesn't have to deal with garbage - You need XPath to query XML directly if you don't want to convert it to something usable - You need XSLT as a scripting language where the DOM isn't alien and awkward to manipulate This is why there is no xslt equivalent (although you could argue that jq is that) and the various json schema solutions don't see much adoption, despite json being almost as old as XML at this point.
- lp4vn 4y ago
  Honestly I don't agree with you, the abstract concept behind XML is just to provide a metalanguage for the representation of hierarchical data, and that's exactly what JSON and YAML do. They are completely interchangeable. XML is the general case for hierarchical data and provides tools for this general case. JSON got closer to the representation of list and hashmaps, but I see this as a mere convenience. >This is why there is no xslt equivalent (although you could argue that jq is that) and the various json schema solutions don't see much adoption, despite json being almost as old as XML at this point. I think it's incorrect to part from the assumption that nobody's gonna need a schema language, a query language, a mapping language or whatever. For the json schema this is blatantly untrue and you see many people creating their own version of a json schema because it's really needed. With XSLT you have a language for processing XML that's written in XML itself, what I find pretty nice. We're not gonna see a YAML processing language written in YAML any time soon though.
  - tannhaeuser 4y ago
    > the abstract concept behind XML is just to provide a metalanguage for the representation of hierarchical data No it isn't, for the umpteenth time. It is a language for marking up text. Markup language deal with grammars - data serialization not data models, and if anything, having regular content models is a more characteristic property for markup languages compared to hierarchy.
otabdeveloper4 4y ago
JSON is not a markup language, it is a serialization format.
- kaba0 4y ago
  A bad one at that. Not the worst (which would be yaml), but certainly not great.
bawolff 4y ago
Because worse is better (which i mean in the unix sense of the phrase). On the specific subject of schema, i think most of that is most users have no need or interest in a schema.
- lp4vn 4y ago
  >On the specific subject of schema, i think most of that is most users have no need or interest in a schema. You have no idea, my friend. I came many times across the situation where people needed to have a JSON conformant with a schema and they just resorted to the ad-hoc badly written json-schema library du jour.
- college_physics 4y ago
  > most users have no need or interest in a schema that is a strange statement. users must reach out for a schema practically as soon as some data is exchanged the only users that don't need a schema are the ones operating within a controlled environment where everything has been somehow agreed or imposed (e.g. within a walled garden or when you control both sides of the exchange) missing, incomplete, low-information schemas about what data is supposed to mean and how it can be used correctly etc is a major, major wast of time. in data science circles the joke is that 90% of the work is "data cleaning". what do you think data cleaning is about?
  - dfox 4y ago
    I think that the point there is that most users (and especially for RPC-ish applications, which is what most of the existing XSD documents are about) do not need a formal schema but the schema is only implied by the implementation. The issue there is that even if you have detailed formal schema and generate the interface code from that, there is still some ad-hoc contract between the generated interface code and rest of this application, and details of this ad-hoc contract will invariably leak through the interface code. Designing formats for long term storage of some kind of data is another thing and there formal schemas make sense. But that is not something that most users (meaning developers) do frequently or often even ever.
  - GoblinSlayer 4y ago
bambax 4y ago
Completely agree! But I think you meant "XSD" here: > you can find the XSL to ensure the validity of an XML document
- lp4vn 4y ago
  Thanks!
valenterry 4y ago
JSON is not a reinvention. It's two different things. XML is a markup language. It's for markup, so, do you need markup? Then don't use JSON. You don't need markup? Then don't use XML.
- GoblinSlayer 4y ago
  Markup is syntax that gives structure to text. Ironically there's a port of HTML to JSON syntax. Guess who did it.

by lp4vn 4y ago

college_physics 4y ago

> for no clear purpose performance may have been one driver, though for the "API web" which is the main use case there are better performing options than json > everything looks like a waste of time overall maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate.

lp4vn 4y ago
>maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate. Agreed.

dtech 4y ago

The reason is pretty clear, XML and its ecosystem was (is) enormously complex. When naively - but correctly - parsing introduces serious security vulnerabilities [1] you kinda have problems as a format. XML is just incredibly hard to get correct, understand, and be performant. JSON from the get-go was very easy to understand and start with so it gained the upper hand. [1] https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://owasp.org/www-community/vulnerabilities/XML_External...

deleted 4y ago
[deleted]
butlerm 4y ago
I wouldn't consider that a parsing vulnerability - XML is relatively easy to parse - but rather an XML processing vulnerability, as in you must disable certain features (like arbitrary filesystem access) when processing an untrusted document. With hindsight, an XML processing library should require that you turn features like that on, rather than require that you turn them off. Opt in to dangerous features rather than opt out of them in other words.

tannhaeuser 4y ago

> that's what an old professor told me Well then your prof has no idea what (s)he's talking about I'm afraid. XML is just what the spec says on page 1 sentence 1 [1]: > The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. Where "generic SGML" refers to the property of XML being always fully tagged and not needing markup declarations, but still able to make use of those for validation and limited forms of entity expansion. Full SGML OTOH uses markup declarations for tag inference/omission (as in HTML), attribute short form canonicalization (also as in HTML), Wiki syntaxes (as in markdown), stylesheets (as in CSS), and other features such as type safe/injection free templating, processing pipelines/document "views" and as general extension mechanism. [1]: https://www.w3.org/TR/REC-xml/ https://www.w3.org/TR/REC-xml/

EdiX 4y ago

XML was a bad fit for almost everything people did with it. The natural data model of XML is alien to all programming languages people use: it is alien to scripting languages because you want hashmaps and lists and it is alien to static languages because you want structs and lists. So you usually ended up having to have a two stage parser, with the first stage turning XML into some kind of DOM and then your handrolled DOM-to-internal-representation thing. That's also most of the justification for XML's ecosystem: - You need XSD to make sure that your DOM-to-internal-representation code doesn't have to deal with garbage - You need XPath to query XML directly if you don't want to convert it to something usable - You need XSLT as a scripting language where the DOM isn't alien and awkward to manipulate This is why there is no xslt equivalent (although you could argue that jq is that) and the various json schema solutions don't see much adoption, despite json being almost as old as XML at this point.

lp4vn 4y ago
Honestly I don't agree with you, the abstract concept behind XML is just to provide a metalanguage for the representation of hierarchical data, and that's exactly what JSON and YAML do. They are completely interchangeable. XML is the general case for hierarchical data and provides tools for this general case. JSON got closer to the representation of list and hashmaps, but I see this as a mere convenience. >This is why there is no xslt equivalent (although you could argue that jq is that) and the various json schema solutions don't see much adoption, despite json being almost as old as XML at this point. I think it's incorrect to part from the assumption that nobody's gonna need a schema language, a query language, a mapping language or whatever. For the json schema this is blatantly untrue and you see many people creating their own version of a json schema because it's really needed. With XSLT you have a language for processing XML that's written in XML itself, what I find pretty nice. We're not gonna see a YAML processing language written in YAML any time soon though.
- tannhaeuser 4y ago
  > the abstract concept behind XML is just to provide a metalanguage for the representation of hierarchical data No it isn't, for the umpteenth time. It is a language for marking up text. Markup language deal with grammars - data serialization not data models, and if anything, having regular content models is a more characteristic property for markup languages compared to hierarchy.

otabdeveloper4 4y ago

JSON is not a markup language, it is a serialization format.

kaba0 4y ago
A bad one at that. Not the worst (which would be yaml), but certainly not great.

bawolff 4y ago

Because worse is better (which i mean in the unix sense of the phrase). On the specific subject of schema, i think most of that is most users have no need or interest in a schema.

lp4vn 4y ago
>On the specific subject of schema, i think most of that is most users have no need or interest in a schema. You have no idea, my friend. I came many times across the situation where people needed to have a JSON conformant with a schema and they just resorted to the ad-hoc badly written json-schema library du jour.
college_physics 4y ago
> most users have no need or interest in a schema that is a strange statement. users must reach out for a schema practically as soon as some data is exchanged the only users that don't need a schema are the ones operating within a controlled environment where everything has been somehow agreed or imposed (e.g. within a walled garden or when you control both sides of the exchange) missing, incomplete, low-information schemas about what data is supposed to mean and how it can be used correctly etc is a major, major wast of time. in data science circles the joke is that 90% of the work is "data cleaning". what do you think data cleaning is about?
- dfox 4y ago
  I think that the point there is that most users (and especially for RPC-ish applications, which is what most of the existing XSD documents are about) do not need a formal schema but the schema is only implied by the implementation. The issue there is that even if you have detailed formal schema and generate the interface code from that, there is still some ad-hoc contract between the generated interface code and rest of this application, and details of this ad-hoc contract will invariably leak through the interface code. Designing formats for long term storage of some kind of data is another thing and there formal schemas make sense. But that is not something that most users (meaning developers) do frequently or often even ever.
- GoblinSlayer 4y ago

bambax 4y ago

Completely agree! But I think you meant "XSD" here: > you can find the XSL to ensure the validity of an XML document

lp4vn 4y ago
Thanks!

valenterry 4y ago

JSON is not a reinvention. It's two different things. XML is a markup language. It's for markup, so, do you need markup? Then don't use JSON. You don't need markup? Then don't use XML.

GoblinSlayer 4y ago
Markup is syntax that gives structure to text. Ironically there's a port of HTML to JSON syntax. Guess who did it.