20 ms·
Most people who lambast XML probably have never used XML or never had to need XML. I designed a complex data acquisition system and after a lot of research, I
by kumarvvr 3y ago
Most people who lambast XML probably have never used XML or never had to need XML.
I designed a complex data acquisition system and after a lot of research, I settled on XML as the only viable option for complex user configuration, that is both readable and rich in content.
I then built a UI system that works with the XML and generates cofig docs with ease.
Sure, XML has been used in SOAP like systems, and it rightfully gets a bad rap, but that is more on the user than the technology.
A hierarchical document with values and attributes and custom tags? That is an almost DSL in itself.
- altcognito 3y agoI can’t help but agree that if we had just built better tools, xml would have had better adoption.
- fzeindl 3y agoI find XML tool in general feature complete and great. Especially editor integration works great as opposed to YAML which is so ambiguous that it IntelliJ IDEA constantly breaks indentation during copy and paste.
- Spivak 3y agoAnd better conceptual docs because it's supposed to be that elements are complete deserializable objects. Having to resort to xpath as the default way of poking at XML where JSON has a good implicit default schema made XML feel so clunky.
- wokkel 3y agoAt least xml has xpath ;-) the implicit Jason to object mapping has failed me on character encoding (no way to specify that in json). Stupid type errors (date/large numbers).
- MenhirMike 3y agoI actually think that XML has some of the best tooling in the entire industry. The problem is: It's mostly commercial tooling, which costs money. Stuff like Oxygen or XMetaL is pretty neat, and I always found Visual Studio's "Create Web Client from SOAP" pretty useful (especially if the Web Service is written in .NET, since it auto-generates a proper WSDL file).
- pjmlp 3y agoXML is all about tooling, but most FOSS folks insist in holding it wrong, editing XML files in vim/emacs.
- unscaled 3y ago> I then built a UI system that works with the XML and generates cofig docs with ease. I lost you there. Not that I'm criticizing you since I've gone the same route and built a complex UI tool to manage said config (complete with XSD schema validation and config schema migration using XSLT for version upgrades). But now I realize that modern developers don't want a GUI to manage their config. We want to store it git, review changes and perhaps even write our own automation and templating around it. YAML is certainly a flawed format for most of these purposes, but so is XML. It is unnecessarily verbose and it carries a lot of complexity which was designed for a highly-extensible generic document format, but not for configuration files. XSD, Namespaces, Entities, Embedded DTD, CDATA blocks... You can't just ignore all of these, and there are very few parsers out there which work on a well-defined subset of XML. And even there, the whole attribute-vs-child-element choice is a giant distraction and constant source for unnecessary bikeshedding. YAML has serious ambiguity issues, but there are better alternatives that have great library support like TOML. We don't have to go back to the excesses of the early 2000s and use XML as a configuration format.
- CableNinja 3y agoI recently started a new project, and just outright didnt want to use yaml to do it. Sadly, im not everyone, and if i plan to release this project, i need to account for that. Whats a guy to do? Ill tell ya hwhat... I made some simple functions; one to load any yaml/toml/json from file, by just looking at the extension (and providing an override for not normal file extensions). Another to output any data as yaml/toml/json. I defaulted to using toml for my project, but have provided ways for everyone to be happy, with zero mucking around. Aaaaaand for the not so subtle promotion, https://pypi.org/project/atckit https://pypi.org/project/atckit Located in the UtilFuncs class.
- elzbardico 3y agoWhat is the point of substituting yaml for something even worse?
- CableNinja 3y ago
- appplication 3y agoThe problem is that xml just isn’t particularly human readable. I don’t think there’s more to it than that. The brackets just make it overly verbose and difficult to read at a glance.
- jimmaswell 3y agoI find it very easy to read. The additional structure only helps. Why does anyone have a problem reading XML?
- kumarvvr 3y agoI have heard this again and again. But to me, well formed XML is incredibly easy to read and skim. I don't feel the same ease with JSON or YAML though.
- Aeolun 3y ago> I don't feel the same ease with JSON or YAML though. I imagine the same is true for people that don’t like XML. There’s just many more people that find it easy to read JSON, even though there are a few that find it easy to read XML.
- dmje 3y agoYes! I find JSON so, so hard to read compared to XML. I thought I was the only one :-)
- wokkel 3y agoYour not alone: it's verboden requiring " around anything that is a string. Commas to separate array elements. It's a technical format without the technical foundation. It's the civil engineering equivalent of building the Golden Gate Bridge out of wooden beams as that is what you have, not what you need.
- pjmlp 3y agoYou are not alone.
- 3y ago
- makeitdouble 3y ago> I then built a UI system that works with the XML and generates cofig docs with ease. It looks like you're experience is mainly with XML as an underlying format, with human only dealing with it either at the coding level or through a tool generating the needed confs. In that kind of scenario I'd wager any coherent file format would probably work, even if the configs where encoded in brainfuck in the final step. XML gets hated because we also had to read it and hand edit it as humans, when dealing with system configuration files (the source that will generate the rest of the configuration) and other upstream documents that are the base input for the system to read downstream when the GUI aren't available for that. I've worked with a Symphony code base that used XML for all the routes and DI declarations, and yes it was an utter pain to write an edit tags for such simple and repetitive configurations when even an ini file would have been good enough. And god have mercy of the guys that put CDATA sections in the middle of that just to be sure CJK chars wouldn't accidentaly trip the syntax.
- bradgessler 3y agoMy issue with xml for configuration files is not understanding when to use elements vs attributes to describe data. The nice thing about JSON, TOML, and YAML is they have implicit structures for arrays and key/values encoded within them. XML has a lot of different ways of representing data that way, which is what makes it a challenging configuration file format.
- wokkel 3y agoThe main reason i avoid any typeless language is dates... how do i represent a date/time including a time zone has been badly reinvented so many times. A string type is never the way to go there in my opinion.
- bradgessler 3y agoWhat’s the best representation you’ve seen for dates?
- stackedinserter 3y agoUNIX timestamp. Plus timezone string, in separate field/column, if it's important for the use case (like calendar events, etc).
- XorNot 3y agoEpoch time + GPS coordinates. That's as unambiguous as you could possibly make it IMO.
- taeric 3y agoHasn't https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 basically won, at this point?
- Smaug123 3y agoOne of the classic lessons of the Falsehoods Programmers Believe about Time is that in general you can't correctly do better than simply storing the user's input (and the instant and place they entered it from) verbatim, unless you know something more about what they were entering. It's usually fine to store times in the past as a timestamp since the epoch plus a location, but the meaning of "2025-01-28 15:00 in Europe/London, for the purpose of a meeting that's being hosted there but is accessible by video call" is much more subject to change when e.g. countries change time zone. It's also not necessarily the same as "the absolute point in time 2025-01-28 15:00 assuming London's time zones stay as predicted since I entered this on 2023-09-21" or "2025-01-28 15:00 in Europe/London, for the purposes of a meeting that's being hosted in Lisbon but which I'm accessing by video call from London" (because then the Lisbon local time is the source of truth, not the London one, if Lisbon changes time zone).
- emodendroket 3y ago> Most people who lambast XML probably have never used XML or never had to need XML. This seems like an absurd thing to say. XML went through an extreme bout of popularity. Maybe you could plausibly say that people have been soured on XML by ill-conceived uses for it that don't demonstrate its strengths... but you think most people have never worked with it? Come on.
- wokkel 3y agoI've done my fair share of systems integrations and the number of teams that did not know xml or have never used it in a professional settings was around 20%. Of those who did use it a staggering amount of people never understood namespaces and started testing for equality on the element name and namespace prefix string instead of the namespace declaration. When somebody claims they "know" xml I initially treat it as a developer saying that he/she knows 'sql' while reviewing their code and seeing them do joins in the application logic.
- pastage 3y agoThat is the problem with XML, there is so much logic that is needed in the application so to be able to understand it. You just need so much knowledge.
- yyyk 3y agoIt depends on what age you are and whether you work with documents. If you started working in the industry past 2010 and didn't have to work with generating/reading (X)HTML/OOXML/ODF than it's rather likely you've never had an experience with XML (fortunately SOAP was deprecated very quickly).
- bryanrasmussen 3y ago> Maybe you could plausibly say that people have been soured on XML by ill-conceived uses for it that don't demonstrate its strengths... but you think most people have never worked with it? Come on. https://truelist.co/blog/software-development-statistics/ https://truelist.co/blog/software-development-statistics/ So, according to the link - The average software developer age is between 25 and 34 years. I think we should also define - are we talking about people who have worked with XML because they made a google site settings xml file OR people who have done serious work with XML and know what they're talking about? First type - pretty much everyone. Second type - not very many. I'm pretty much the only person who knows anything about XML wherever I go. if you are 25 you have probably not done anything with XML or at least not anything important. If you are 34 you might have, but I mean the last time I did anything really important with XML was 2013, I did a few other things since then because I knew XML was the best solution but that was me or because there was a very niche thing I was doing and the company was providing an XML api. I bet most of the age 34s have not done anything meaningful with XML either, even though if you are 34 I suppose you probably had some ticket at some point that took you a week and you thought wow, my extensive experience with XML now gives me the right to grouse about how bad it is! If only everybody knew as much as I the world would be a better place! on edit: my example of google site settings file is an example of some trivial usage, not meaning that pretty much everyone has done that exact trivial usage.
- lmm 3y ago> I settled on XML as the only viable option for complex user configuration, that is both readable and rich in content. How was it more readable or richer than JSON? There's more stuff in XML, but in my experience that stuff doesn't actually help you any. The schema validation has a lot of detail, but since it can't access your actual system you can't really validate in that detail (like, maybe you can validate that an ID is between 6 and 8 digits long, but really you just want to validate that it's an ID for something that's present in your database). The distinction between attributes and nested tags feels like it should let you express more, but in practice it usually just gives you two equally reasonable ways to write the same thing and causes more confusion. Comments and non-tag text nodes feel nice, but complicate your parsing more than they're worth. > Sure, XML has been used in SOAP like systems, and it rightfully gets a bad rap, but that is more on the user than the technology. If one person uses the technology wrong, it's a problem with that person, but if most people use the technology wrong, it's a problem with the technology.
- frant-hartm 3y ago> If one person uses the technology wrong, it's a problem with that person, but if most people use the technology wrong, it's a problem with the technology. But yaml has the exact same problem. People use it where they shouldn't.
- lmm 3y agoI'm not a big fan of YAML, but I think it has a better "hit rate" than XML.
- ExoticPearTree 3y agoDo a mental exercise and think about what would k8s with XML configuration would have looked like and if would have taken off like it did using XML for configuration instead of YAML. This is just an example. Besides Microsoft frameworks that use XML as configuration, and Java frameworks and servers using XML for configuration (Tomcat comes to mind), no one else uses it. Maybe traditional software whose programmers don't know any better. So yeah, I think the world doesn't like XML for really good reasons.
- thayne 3y agoI have used XML a fair amount in past years, but now avoid it. There is a subset of XML that a decent language for some use cases. In particular it is good for documents whete you want a _markup_ language. But I've seen it used for a lot of things where it wasn't a great fit. And xml has too many features, which leads to implementations that are inconsistent with each, often slow, and have security problems such as xxe. I wish that there was a standardized simplified xml format, that would avoid many of xmls problems and meet the needs of 90% of applications where xml is a good fit.
- GoblinSlayer 3y agoThe only objectionable feature of xml is dtd, everything else is easy to implement in 600 LoC.
- thayne 3y agoI also think namespacing adds complexity that usually isn't needed.
- GoblinSlayer 3y agoNamespaces can be parsed as attributes, then you can add a namespace resolver as a third party algorithm.
- NonNefarious 3y ago[dead]
- agumonkey 3y agotoo much energy wasted on endless xml schema debates while a bit of { a : [1,2,3] } was enough to do 80% of your job this plus, like GP said, java ee xml bloat culture made it too much of a pain
- ExoticPearTree 3y agoI have a deja vu over YAML and XML. There was a similar discussion about this a month or so ago, IIRC. And I haven't changed my opinion since then, having worked extensively with XML: it is a plague that was brought on into the world and it needs to be killed with fire. I understand that when it was released there were no other alternatives so "it was better than nothing", but it should have died right after JSON was invented. But no, why have cleanly formatted file when you can have an XML one...
- GoblinSlayer 3y agoJSON syntax is optimized for serialization and thus unsuitable for other purposes, and for serialization loses to binary formats except for one use case: it's a serialization format that can be nicely embedded in html.
- kllrnohj 3y agoThe game Rimworld uses XML for describing all of its game objects and it makes modding a fantastically wonderful system as you can modify/replace parts of the object using XPath. The end result is mods rarely conflict as they are able to target the specific mutations they want quite easily https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperations https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
- trilobyte 3y agoI have delivered XML data products comprising terabytes of information in (when I last checked) more than 800 schemas to companies around the globe, and people who have a rosy view of XML are using missing how it usually works in practice. XML is extremely heavy and brings a lot of half-baked ideas, and consumers are almost never flexible in ingesting the XML. It means teams wind up supporting insanely convoluted schemas that customers will never migrate off of.
- gjvc 3y agoReal XML has never been tried.