25 ms·
What's wrong with XML?
by shmerl 6y ago
What's wrong with XML?
- hinkley 6y agoI’ll start. Take an XML document. Validate it. Take all of the top level elements. Call getElementByID on each with the same value. Combine all the answers into an array, eliminating the nulls. You might expect that array to have length one or zero on all valid documents. You’d be wrong, and dangerously so for some XML schemas. You can use the same ID on every node and I don’t know of a parser that would balk at that. And yet every implementation will return the first node that has that ID, which will then change any time you descend into the DOM.
- _-___________-_ 6y agoParent asked what's wrong with XML, not what's wrong with DOM. Does XML actually even define a special meaning for the `id` attribute?
- hinkley 6y agoThe XML element object always has this function, in every implementation I’ve seen.
- _-___________-_ 6y agoThat does not make any sense. There are entire classes of XML parser that cannot implement getElementByID, such as streaming parsers. getElementByID is specified as part of the Document Object Model (DOM), not as part of XML. I don't think `id` even has a special meaning in XML.
- shmerl 6y agoI presume JSON is less ambiguous and easier to validate and parse?
- Erlich_Bachman 6y agoJSON doesn't even have IDs, so in this particular regard the (similar) tool to what the poster uses doesn't even exist for JSON. So no, it would not be correct to say that in this particular regard JSON is somehow easier to parse.
- formerly_proven 6y agoNever seen getElementByID being used for XML data (not somethinghtml)...
- hinkley 6y agoThis is the one half of my bad experiences are associated with: https://www.w3.org/TR/xmldsig-core/ https://www.w3.org/TR/xmldsig-core/
- formerly_proven 6y agoWell, XML Signatures and XML Encryption are a confluence of bad ideas from many disciplines :)
- brmgb 6y agoIf only you could specify in your schema that element must be unique. But wait a minute ! Actually, you can. That's what the unique attribute does. And here lies the main problem of XML. As a technology, it is better than its reputation. Sadly, next to no one knows how to use it properly.
- nine_k 6y agoXML did a number of things right. Too bad it was initially envisioned as a text markup language, with tags sparsely strewn around the text, and not as a data representation format. So, the syntax ended up both overly cumbersome (see closing tags) and festooned with logically unnecessary shorthands like node attributes. Then, the terror of entities. XSLT is a brilliant language, I'd say the first pure functional language widely used outside academia (in 2000s), but, based on XML syntax, it's completely unfit for human consumption. If only the authors of XML could get rid of the shackles of SGML compatibility, and went with a simple, uniform syntax, e.g. s-expressions, we could still be gladly using it. Now we reinvent the ecosystem instead, with JSON (sigh) and YAML.
- wokkel 6y agoI see no issue except from the entities. Which by and large have died anyway as those come from DTDs and not from XSDs. I do not see why closing tags are a problem: my editor will insert them and it makes parsing the XML much easier/less error prone. XSLT is brilliant indeed (and to my eye quite readable, but then again I also like regexp ;-)
- hinkley 6y agoYou can’t specify that attributes are unique, which is why id is broken. And thus why XML DSIG, which uses id extensively, is exceedingly difficult to harden.
- Erlich_Bachman 6y agoWhy aren'y you just using xpath? There are mature and powerful xpath libraries in all major languages. Of course if you use only one limited tool which was never meant to be the main manipulator of xml (getElementByID), then you'll run into problems. It is like never using regexp and complaining that simple strings are a bad data structure.
- hinkley 6y agoXpath still uses the same broken DOM functions under the hood. Exact same outcome.
- Erlich_Bachman 6y agoThat just doesn't make any sense. Regardless of what functions are used "under the hood" (how do you even know that? Did you go through every xpath library? What do you even refer to when I use an xpath library in php to open an xml document. There isn't even a web page or "DOM" to speak of, there is no browser, no JavaScript, it's just xml.), the interface provides you with ability to select whatever you want from an almost arbitrarily complex xml document with 1-liners of xpath. This is not the same outcome as getElementByID-acrobatics.
- deleted 6y ago[deleted]
- Polylactic_acid 6y agoIm sure there are better answers here but my main issue is that attributes and child elements offer duplicate functionality. You could have <point><x>4</x><y>5</y></point> or you could have <point x=4 y=5 />. There is often no consistency within a single spec over how this should be done let alone between different specs. JSON feels much more logical to me as well as being a whole lot simpler. If only it supported comments.
- shmerl 6y agoYeah, I agree. Though I usually view elements as data and attributes as metadata, but in practice the usage is all over the place.
- agumonkey 6y agoOr it results in neverending discussions about when to do what and why it's somehow better
- andyjohnson0 6y agoThe functionality isn't quite duplicated. Attributes are order-independent and can't have child attributes, for example. As far as I know, the original intention of the language designers was that attributes are for metadata and sub-elements are for data. For non-trivial schemas that form part of a data contract between systems or organisations, and/or are expected to evolve over time, I tend to stick to this approach. It results in more verbose data, but in my experience thats almost never a problem and can be an advantage if I have to drop into the data and actually read it. For smaller-scale and internal schemas (e.g. internal tool configs) the terseness of e.g. <add key="foo" value="bar"/> definitely wins out over design purity for me. JSON would be equally good for this. I work on enterprise integration and messaging stuff and I deal with a lot of XML data every day. JSON has its uses (particularly when you control both ends of the serialisation pipeline) but for me XML has a lot of advantages.
- tonyedgecombe 6y agoI always assumed attributes unless I was dealing with a composite or enumerable type. Of course if someone else is producing the data then they can make a mess of things but I don't think that is specific to XML.
- laurencerowe 6y agoFor those working in dynamic languages (JavaScript, Python, Perl, Ruby, etc.) JSON maps directly onto built-in language data types and structures making it trivial to work with. With XML you usually end up needing custom code to convert to and from the parsed XML representation and the language's built-in data types and structures. This is less of a concern for statically typed languages where you usually have to marshal data to and from your own structs/classes whether it's XML or JSON.
- wokkel 6y agoIt's trivial until you run into a date-field. I've connected some JSON based exchanges to each other and just created an XML intermediary format to have a single canonical model and do the various translations to/from the other systems from there.
- Macha 6y agoWhy are dates better in XML? You can still have: ISO 8601, as used by XML Schema: <foo>2020-09-04T00:00:00Z</foo> or Unix date output format (not sure this has an actual name) <foo>Fri 04 Sep 2020 00:00:00 GMT</foo> or some sort of destructured date <foo> <year>2020</year> <month>09</month> <day>04</day> <!-- ... --> </foo> or some sort of destructured date with 0 based months because Java <foo> <year>2020</year> <month>08</month> <day>04</day> <!-- ... --> </foo> Your app still needs to know what is coming in, and convert that to its internal format. Even if you want to get everyone to agree on XML Schema's datetime format, it's not always sufficient because sometimes you need the actual time zone (e.g. America/New_York ) rather than the UTC offset especially when dealing with recurring/far off events.
- riffraff 6y agoXMLRPC[0] defined a trivial mapping of the same data structures (structs, arrays, scalars) in the '90s. The real advantage of JSON was (IMHO) that it didn't let you do _anything else_. [0] http://xmlrpc.com/spec.md http://xmlrpc.com/spec.md
- tonyedgecombe 6y agoThe biggest problem for me is when people try and squeeze it into something it was never really meant for. I'm thinking of things like ANT files or XAML. In both of those cases they are too verbose and difficult to edit by hand. They are building an object model that would be better expressed as code.
- cuillevel3 6y agoXML can be used to represent data formats, but is missing things like types. It's powerful enough to represent documents, which might be too much for data structures: <a>This is <b>valid</b> XML</a> And let's not forget how hard it is to escape data in XML, so every value ends up as CDATA in the end. <config> <somekey type="string"><![CDATA[4byte emojii]]></somekey> </config>