16 ms·
The Goals of XML at 25: and the one change that XML now needs
- tannhaeuser 5y agoFWIW, there's a discussion on the xml-dev mailing list [1], where the article was initially submitted to by the author. [1]: http://lists.xml.org/archives/xml-dev/202107/threads.html http://lists.xml.org/archives/xml-dev/202107/threads.html
- flakiness 5y agoWow, this list still exists! Thanks for the pointer. You made my day. When XML was cool I was subscribing the list and followed (or tried to follow) the discussion. It was my first exposure to the Web standard world. The archive suggests that the list is mostly dormant, but still.
- riedel 5y agoNot sure if I get the argument, however I can echo that many benefits of the XML ecosystem are given away because of compromises. I really would like to see a sound schema-driven XML landscape that takes the learnings from hedge or visibly pushdown automata and makes sure that you can actually parse, validate and transcode XML (e.g. to binary representations) fast. I really am fascinated by the possibilities of grammar based compression on XML like done in the MPEG7 standard (I think it's used in DVB-T). Would have been great if XML could have at least replaced ASN.1 . XML should simply support different encodings natively. If you just want something readable and heavily extensible there seams no reason against JSON .
- saurik 5y agoFWIW, XML was long long ago abstracted as XML Infoset--which essentially represents the concept of an XML document as opposed to a specific text encoding with angle brackets and quotation marks--so it has always felt to me like "different encodings" are already "support[ed]...natively"?
- dasyatidprime 5y agoYou should look into https://www.w3.org/TR/exi/ https://www.w3.org/TR/exi/ if you're interested in binary XML encoding.
- riedel 5y agoLooked at it and I don't see much value. Tool support seems minimal particularly for embedded systems. Unfortunately there were few competitors and not much love involved when this was standardized. IMHO
- ram_rar 5y agoIts too little too late. XML tried to do too many things. The web always loves things that are quick and dirty. JSON with all its shortcomings was simple enough to get going. Couple it with HTTP, you can easily get a web service up and running. I wonder, for what are the use cases today one would prefer XML over JSON/GRPC/GraphQL etc ?
- tannhaeuser 5y agoXML was introduced as a simplified SGML subset to base new versions of HTML (XHTML) and other web vocabularies (SVG, MathML) on, but that failed and HTML5 still continues to use tag inference, shortforms, and other SGML features that didn't make it into XML. It wasn't conceived as a payload format for web services.
- Ygg2 5y agoThere was a desire to do similar for XML. See XML5 than Anne van Kestren worked on. https://annevankesteren.nl/2007/10/xml5 https://annevankesteren.nl/2007/10/xml5 I wrote a parser for it, but it never got traction. I might have to rewrite it again.
- skissane 5y agoPersonally I prefer Tim Bray's XML-SW to Anne van Kestren's XML5: http://www.textuality.com/xml/xmlSW.html http://www.textuality.com/xml/xmlSW.html XML-SW drops the internal DTD subset entirely, including entity declarations; this means it doesn't support named entity references except for the predefined ones (apos, quot, gt, lt, amp). I think DTDs are one of the ugliest things in XML (and also a well-known source of security vulnerabilities), and it is great that XML-SW (unlike XML5) mostly kills them. I'm also not sold on the whole "HTML-style error-recovery" idea in XML5. In my mind, the syntactic strictness of XML is a virtue not a vice. I'd support killing processing instructions as well. They are rarely used, and XML namespaces could be used as a replacement.
- AlbertoGP 5y ago
- pimterry 5y agohttps://web.archive.org/web/20210718172613/https://schematron.com/2021/07/the-goals-of-xml-at-25-and-the-one-change-that-xml-really-has-needed/ https://web.archive.org/web/20210718172613/https://schematro...
- AtlasBarfed 5y agoXML didn't work as a data interchange. JSON and YAML (and TOML etc etc) beat it handily. XHTML was a failure, rejected and ditched. So if it lost data interchange and layout/interface specification... what is XML's relevancy (not counting legacy interaction/systems)?
- robin_reala 5y agoXHTML was ditched on the web, sure, but it survives in ePub.
- vbezhenar 5y agoXHTML was not ditched on the web, it's supported by all major browsers, at least for now, and I'm not aware of any plans to deprecate it.
- krapp 5y agoIt was ditched on the web because no one on the web is using it. Everyone would rather have sites that fail gracefully on markup errors than crash in the browser.
- acdha 5y agoIt was never widely used, however, and in many cases those documents were parsed as HTML because the server was never configured correctly — I believe actual correct usage is well under 1% – so I would not be making any new investments in that direction. The big thing I'd be curious about is what happens when new features are added: do they get added to the XHTML parsers as well or does that become a legacy path drifting behind the main web platform? I believe there were already some issues with Chrome along those lines when they added JS modules, for example.
- WorldMaker 5y agoThe XHTML 2.0 "standard" was ditched on the web as no major browsers wanted to support it (and mostly still don't [1]). Also, most browsers today no longer support XHTML 1.x "Strict" modes, the errors they surfaced, and instead just laxly parse all XHTML 1.x with the same parsers they use for "HTML5". (IE11 I believe was the last browser with XHTML "Strict" support and used a proper XML parser and error reporting when parsing XHTML.) [1] Outside of how XHTML 2.0 influenced HTML5's list of "semantic DIVs" the tags like ARTICLE and SECTION that don't have any meaningful semantics in current browsers but are nice when you get bored of surrounding everything in DIV. XHTML 2.0's standard attached actual meanings to those tags and had a lot of specified behavior for how those tags would operate. The only surviving "tag behavior" from XHTML 2.0's plan was DETAILS, I believe. I also believe the exact lists of tags are disjoint and XHTML 2.0 had tags that didn't even make into the official "semantic DIV" bucket, are out of spec in HTML5, but HTML5 browsers will mostly just ignore and fallback to treating unknown tags as fallback DIVs anyway.
- tored 5y ago> Error establishing a database connection Goals of XML. Anyone else terrified yet?
- Ind007 5y agoyes, many XML parsing libraries doesn't have sane defaults...it is a security nightmare.
- ferryman 5y agoFor the OP/Author: The link is not working for me at the time of posting this comment. I get "Error establishing a database connection". I think you got the HN hug of death
- Kognito 5y agoMirror: https://web.archive.org/web/20210718172613/https://schematron.com/2021/07/the-goals-of-xml-at-25-and-the-one-change-that-xml-really-has-needed/ https://web.archive.org/web/20210718172613/https://schematro...
- ksec 5y agoStill dont understand why is CDN, or something basic like caching not on by default in 2021.
- cryptos 5y agoOr maybe a somewhat crazy solution like static HTML files ...
- ksec 5y agoI actually think static HTML is not a "crazy" solution at all. For like 99% of blog there is no need for a Database for dynamic page view. Modern CPU and SSD is so fast just regenerate all the page. Not using something nerdy like the JAMstack, go back to good old FrontPage or Dreamweaver style.
- majewsky 5y agoYou don't actually need a CDN or caching to survive being on the HN frontpage: https://xyrillian.de/thoughts/posts/latency-matters-aftermath.html https://xyrillian.de/thoughts/posts/latency-matters-aftermat...
- anothernewdude 5y agoPersonally, I hated the namespaces and the attempts at validation. It's also too many characters.
- silon42 5y agoCan't see the article, but for me the reason why XML is bad (still not as bad as YML) is the lack of support for some control characters. Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] There's no good reason to do this (even null character, although C will not like it).
- zip1234 5y agoI feel like XML just needed a revision to remove a bit of cruft, simplify, add ways to handle certain characters, and a few other things. Instead we have YAML...
- ajnin 5y agoI way prefer XML over something like YAML. I can't believe people criticize XML for being too complex and then rave about YAML. YAML is a monstrosity, the spec is something like 700 pages, and is a frequent source of bugs. To me at least indentation-based hierarchy is also hard to read, XML is verbose but at least you know where you are. JSON would be fine, but some values are not representable, and as the article says, you can't embed any comments, and also the order of input is not preserved. I don't think that is really appropriate for manually-edited files. The quest for the perfect data and configuration language is still on.
- tored 5y agoYAML is not only hard to read it also hard to properly parse and generate. I once tried to read the parser code for the Symfony YAML library, horrible, and that is not a critique against the developers of that library, the format is just too complex.
- whoisthemachine 5y agoAlso hard to edit. Why do we use YAML again?
- curtis3389 5y agoBecause noone wants to dump a ton of work into a JSON parser they can't say is standards-compliant because it also supports C-style comments?
- whoisthemachine 5y agoHm it is interesting that your hypothesis is solely the exclusion of comments from JSON. I can understand the constraint when you consider JSON as a data transmission spec rather than a configuration spec. I also find TOML to be much a cleaner syntax than either of the two, but maybe we should just give up and make a JSON-C (for Configuration, I just made this) which supports comments.
- kstenerud 5y agoThere are three big things that are important for modern data formats: - It must be easy to use. The harder it is to set up, the less people will want to use it. The harder it is to work with, the higher the maintenance costs and the greater the number of mistakes and security holes. Poorly defined specs and a cavalier attitude towards the users of these technologies have trained us to just accept bad quality and make do. - It must be efficient. Text formats are convenient, but wasteful of both CPU and bandwidth. Going forward we need to think more about our energy impact. There needs to be a way to have our cake and eat it too! - It must be worry-free. Codec differences are a security risk. Bad defaults are a security risk. Lack of forward compatibility is a security risk. Today's hostile world does not at all resemble the world in which our current formats were developed. This is why I'm developing https://concise-encoding.org/ https://concise-encoding.org/
- zkldi 5y agoI've seen this posted around quite a lot now and it seems quite interesting. Is there a JS/TS implementation of the spec?
- kstenerud 5y agoUnfortunately not yet. I'm still finishing up the reference implementation in go, and then looking for help with the other implementations. I think there's someone doing a Swift implementation as well...
- mongol 5y agoIt looks quite nice. But also unneccessary complex. Why are there special URL types? Why do the time types not follow ISO8601 but almost?
- kstenerud 5y agoThere's a special URL type because URLs are not strings, and the computer needs to know that. The date format is not ISO8601 because ISO8601 has too much cruft, bad defaults, and is missing real timezone data. I'd have been fine with the cruft and bad defaults, but lack of timezones is a deal breaker.
- KingOfCoders 5y ago"Error establishing a database connection" XML now needs a database.
- thechao 5y agoThe "killer feature" for XML, for me, has been XSL — a language dedicated to transformation of XML. OTOH, there's only one high-quality open-source implementation of that language. Having spent a lot of time in XSL, I think its core feature is the matching-and-synchronization story. Essentially, every XSL template can be cut up into a sequence of CPS blocks that perform a mapping operation on the sub-calls to apply-templates. Porting the matching & template apply syntax to Python is fairly easy — the ergonomics are great! The problem is that mapping operation is functionally impossible for me to implement, efficiently, in Python with parallelism. The result is that even though the big implementations of XSL are 100-1000x slower than Python in terms of serial computation, they handily beat Python in deeply concurrent constructs. My understanding of `asyncio` is insufficient for me to determine if it's even possible to map `asyncio` onto multiprocess pools and get back the data at the yield point. And — even if it were possible — the batteries-included version of ElementTree reloads & reparses the entire document in every subprocesses, completely destroying the performance.
- dionidium 5y agoXSL was misunderstood and misused by pretty much everyone who did try it. Of course, writing code in XML is pretty awful, so that didn't help its reputation, either. But the ideas in XSL -- its declarative/functional nature and simple tree-processing-via-pattern-matching processing model -- were really quite good, especially once you understand it well enough to avoid trying to recreate procedural code with it.
- agumonkey 5y agoIIRC there was a board or mailing list service built on top of xsl only. Prince something. I was surprise by the near zero lag between requests (no Ajax I believe)
- dehrmann 5y agoI can't call XSL a good language, but it's capable and standardized...which is more than JSON equivalents can say.
- majewsky 5y agoIt just says "Error establishing a database connection" for me. ... Yeah, that checks out.
- technicolorwhat 5y agoI work with XML quite a lot for connecting legacy but also 'modern' systems, and there are some good parts and some absolutely horrible parts, let me go on a rant for a little. I classify them as sane XML ideas and some as complete utter garbage. Good parts - Schemas for documents - If you have a single schema file, and a single XML to do validation its KINDA nice. If you limit yourself to a basic set of XSD types its okay ish. - The general idea have XSD's express document structure and have a standard for it is kinda nice. Bad parts - people go absolutely bonkers with schemas, have schemas in schemas, do complicated stuff that can hardly be expressed in modern type systems, and even harder to generate code for. Things like PEPPOL or UBL are extreme horrible overly complex solutions, and you need an army of devs that have the patience to implement it properly. As a result, everybody does the bare minimum and gets their own flavour and you're still making per supplier code since everyone just tries to make it work. Our code base has a ton of 'fixers' per supplier to convert their iffy files to something sane. We started by asking them to fix their files but in the end it was just waaaaaay faster if we dealt with it, because the complexity of truly understanding XSD's is quite complicated. - The a part of the standards community, feels more like schema designers than actually implementers. It feels like whenever a committee designs a standard they're like "WE'RE DONE!" without actually implementing it themselves across languages and see how hard actually is to generate something valid. These organisations are head-acheinducing money sinks where there bad schema ideas trickle down. - It can basically do too much, what you want is a tiny expression of your types. - JSON Interopability: You can't just convert JSON to XML without schema knowledge. In XML this can `<user><name></name></user>` can either be an item in an array [], or a hash. You need to know the schema to understand how to deserialise or generate properly, you can't cheat. - Its super verbose, and hard to read. When you're staring at 200 lines of XML, you're brain has to parse all the verbose namespaces and what not in order to pick out the data. I also deal with +1GB XML files and then the tooling to support large files grows thin. And you resolve to SAX parsing and emitting nodes. It aint fun. In the end I had to write a lot of tools myself to make it manageable to work with many documents. Anyway thanks for reading this far, I really needed to vent hahaha
- acdha 5y ago> - Its super verbose, and hard to read. When you're staring at 200 lines of XML, you're brain has to parse all the verbose namespaces and what not in order to pick out the data. Namespaces are high on my list of decent IDs with botched implementations killing the concept. The thing which made working with them so painful was that the tools pushed all of their work off to the user and did inconsistently. It's not just that you have to know they exist but you have to know that, for example, you're going to need to pass namespace declarations to many APIs because the implementers chose to require those as parameters rather than reading the declaration out of the document being parsed and depending on which tools you have the misfortune of using you might have a source like “myns:foo” but the parser will require you to use "{http://example.org/myns}foo http://example.org/myns}foo" for queries. Similarly, the default could be inherited so you could simply write '<myns:foo bar="baaz"><quux /></myns:foo>' and assume that everything unqualified is in “myns”. Imagine how much better this would have been if, a couple of decades ago, anyone had cared about the developer experience enough to fix the common tools. Non-broken namespacing, good error messages, easy to use validators and formatters, etc. would have removed so much constant friction which lead everyone to run for the door as soon as JSON started to get momentum. > - The a part of the standards community, feels more like schema designers than actually implementers. It feels like whenever a committee designs a standard they're like "WE'RE DONE!" without actually implementing it themselves across languages and see how hard actually is to generate something valid. These organisations are head-acheinducing money sinks where there bad schema ideas trickle down. Imagine if 10% of the money which went into barely-used standards development had gone into maintaining libxml2 (and maybe xerces). Basically any bit of work which went into XPath or related specs after 1999 was a write-off because those later versions effectively never shipped for anyone outside of exclusive .NET users.
- Mikhail_Edoshin 5y agoXML is not like other data format languages. XML is language-like, it's like a typical programming language that comes directly as an abstract syntax tree (AST), without the parsing step. No other data exchange formats are like that. Yet this is exactly what people need to conveniently describe things for machines. So it's not exactly a machine-to-machine exchange format, but human-to-machine and machine-to-human. E.g. one of area where XML shines are user interface notations. A screen may have a tab that has another tab that may show yet another screen; a menu may have a submenu, and (although not recommended) a sub-submenu and so on. A field or text may appear here and there. The two chief things here are ordering and composition. XML is very good at that. Not as good as a dedicated UI language, perhaps, but, being generic, it's much more pliable an easier to tinker with.
- jugg1es 5y agoThere are a lot of great things about XML but I think it started falling out of favor when developers (primarily Java) started converting their internal OOP data structures into XML schemas and used that for all inter-service communication. It's a quick and dirty way to stand up an API and allowed developers to think of APIs as an after-thought. I work in healthcare and its obvious that this happens all the time. It was just too easy to run a tool to convert your OO classes into a WSDL instead of taking the time to design a proper API. I think this had a lot of unintended consequences that has hurt XML in the long-run but has nothing to do with XML itself.
- Nursie 5y agoIs that significantly different from the way people now do this with JSON?
- jugg1es 5y agoThat is a fair point but, anecdotally, I have run into this problem more often with XML APIs than with JSON.
- jugg1es 5y agoAfter some thought, the reason JSON is different is due to how XML schemas include types and if you are converting the OO classes to an XML schema, you are basically injecting inheritance/composition into the actual API call. That does not happen in JSON because you don't have types.
- qalmakka 5y agoXML has always felt to me as both a great and a terrible idea, at the same time. The fact it's built around schemas is great, and this makes it way better at representing serialized structured data on a file than JSON and anything schemaless. On the other hand though, it has perhaps one of the worst syntaxes known to man. I dread reading and writing complex stuff in XML (Plists are one of the worst offenders), as it is often true that a lack of thought at time of schema definition can causes terrible readability problems that tend to linger for years. People are often in a hurry when releasing a new piece of software, and XML makes very easy for a hasty developer to overcomplicate things. Certain pieces of XML basically require you to edit them through the GUI tool that created them, and the punishment for not doing so is having to recover a completely messed up XML file. I am personally a strong believer in the idea that a text file MUST be easy to edit by hand, because someone will always try opening it up in Vim and edit it that way. If a given file format forces you to use (de jure or de facto) a specific program to edit it safely, it should be using a binary representation instead. Binary files are often smaller, and have the unintended additional bonus of making the file not editable in a text editor.
- GoblinSlayer 5y agoIn reality people open the files in microsoft word, hope your favorite format can survive that.
- qalmakka 5y agoI've had to fix more broken JSON files with fancy “„ than I'd like due to people attempting to edit them with Word, so I must say, you have got a point.
- camgunz 5y agoI thought billion LOLs killed XML (and should kill YAML). I don't even consider them when choosing formats. Am I out of date?