4 ms·
In my huble experience: - XML parsers were quite bad in the old days (2000), even in java land. - Parser speed is a functin of the input size. And XML inputs
by daitangio 4y ago
In my huble experience:
- XML parsers were quite bad in the old days (2000), even in java land.
- Parser speed is a functin of the input size. And XML inputs are quite big, too big in my humble opinion.
- you have tag attribute and tag value, and so people get confused on how to use them for simple scenario.
- & must be escaped but no one does it. So when 'AT&T' ended up in a stream created by "hand" by a COBOL procedure, the XML got suddenly broken
- < and > musty be escaped, and so your SQL queries must be escaped
JSON is simply an associative hierarchical maps.
A Lot of 1995 PHP code used the same data structure and just works.
No attribute, only hierachy recursive structure.
Recusion always wins.
- adrianmsmith 4y agoThat's all true, I'd just add that in JSON you have to escape " in strings just like you have to escape & < and > in XML, so there is still the potential for e.g. COBOL software to produce invalid files.
- GoblinSlayer 4y agoJSON: "path\to\file" XML: <a>path\to\file</a>
- bambax 4y ago> Parser speed is a functin of the input size. And XML inputs are quite big, too big You don't have to parse the complete document to do something about it. You can use a streaming parser, and you can execute XSLT on the fly.
- zaphar 4y agoThis is true but in the early days XML framework libraries gained a well deserved reputation for poor performance because they would parse into a DOM first and then serialize from there. I improved the runtimes of several projects from hours to seconds by switching the serialization from DOM to SAX. The prevalence and focus on the document model for every usage of XML resulted in a reputation hit. One that XML has really struggled to overcome.
- Gibbon1 4y agoAround the time xml was released I asked a (smarter than me) friend what the hubbub was. And he got a pained look on his face and said. People think it'll solve a problem and it won't. His reasoning was the problem isn't standard file formats. It's turning those into something a program can operate on as data[1]. And XML does not do that for you. No you have suck it in and then manually transform it into 'data'. So it just moves the problem from one place to another place. Which is a trash solution usually. Far as I know JSON broken as it is does do that. At least with dynamic/ish languages. [1] gross stuff people used to do like copy data structures in memory directly to a file actually solves that problem while being a maintenance nightmare.
- ElectricalUnion 4y ago> Far as I know JSON broken as it is does do that. JSON in scripting languages does "as well" as Java's java.io.ObjectInputStream/java.io.ObjectOutputStream and dontnet's System.Runtime.Serialization.XmlObjectSerializer. aka: will explode in your face in spetacular fashion [causing security vulnerabilities or denial of service in the way] unless you take special care to only use explicit safe serializable objects, and you handle corner cases correctly (for example, Javascript `__proto__` naive deserialization).
- goto11 4y agoI consider this a feature. XML specifies a data exchange format. How this is loaded into memory depends on your use case, language etc. You can use a DOM if this is appropriate or serialize into custom or native data structures. A browser rendering a web page will use different data structures than a crawler indexing a document.
- Gibbon1 4y agoThe problem is the schema and validation is the hard part and XML doesn't help with that at all.
- deleted 4y ago[deleted]