5 ms·
XML is nowhere near "hip" these days, but I think it is underrated. Yes, a lot of bad things have been done with XML, but the technology itself is just fine and
by cryptos 4y ago
XML is nowhere near "hip" these days, but I think it is underrated. Yes, a lot of bad things have been done with XML, but the technology itself is just fine and sometimes hated for the wrong reasons.
XML is considered overly verbose, which is not always the fault of XML, but of how it is used.
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.9.2</version>
</dependency>
Could (in principle) be written as:
<dependency groupId="org.junit.jupiter" artifactId="junit-jupiter-engine" version="5.9.2" />
What really stands out is XML Schema. It is so much more powerful and precise compared to Json Schema.
See also: http://www.nichesoftware.co.nz/2017/04/25/in-defense-of-xml.html http://www.nichesoftware.co.nz/2017/04/25/in-defense-of-xml....
- Hendrikto 4y agoIsn‘t that element vs attribute dichotomy one of the main drawbacks of XML? You don‘t have that with other formats.
- funcDropShadow 4y agoSomehow this is only mentioned as a drawback of XML, not of HTML --- usually.
- raverbashing 4y agoBecause in HTML it's clear what's an attribute and what's content In the case above, not so much (though I'd say it's the artifactId) But since XMLers like waddling in verbosity and bureaucracy it seems they shot their own foot with it
- EdiX 4y agoBecause HTML is a markup language. XML is also a markup language but people somehow insist on using it for things where a markup language is not appropriate (which is almost everything).
- butlerm 4y agoXML is rarely used as a markup language, in fact it is almost a failure as a markup language, witness the non-use of XHTML. It is a markup language that turned out to have more utility as a general purpose data format, and it certainly didn't get that way by people using it for applications it was not intended to support.
- HelloNurse 4y agoIt's usually forgotten that XML is intended as a markup language: text is the main content, text is contained in elements, and elements might have properties (i.e. attributes). Elements with no text children are a special case of mixed content, not the norm.
- butlerm 4y agoBy the time the XML specification was standardized from the more general SGML, I don't think there was any idea of using it only as a markup language. The XML specification lists support for a wide variety of applications as one of the design goals. Even schema validation, which long preceded XML, is something more commonly used for data not text. By this point XML is so rarely used as a markup language (by comparison with its usage as a data format) that the "Markup Language" part of the title is almost a misnomer.
- ivan_gammel 4y agoIt’s ambiguous only until you define a design convention for your schema. The rule can be as simple as using attributes only for simple non-user generated values (eg order, postal code, birth date or name is an element, uuid or timestamp is an attribute). And clients just map whatever defined in schema.
- type0 4y agoA lot of bad rep for XML stems from the decades when it was "when all you got is a hammer, everything is a nail" XML shall be used for Good, not Evil.
- zaphar 4y agoXML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. 9 times out of 10 for data transport you want SAX parsing not DOM. Unless your XML is actually a marked up document DOM is overkill. But many data transport libs used to use DOM which has a very real performance cost. I'm not sure how much of that is still true but the reputation for bloat and being heavy weight was often caused by parsing to DOM and then deserializing from there.
- tablespoon 4y ago> XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. That's not the standard's fault. DOM and SAX (or rather streaming parsing in general) both have their places, it's up to the developer to know when to use which. Of course, developers often make bad choices, but the only way a standard can "solve" that is by forcing a developer to make bad choices in some contexts, so it's not the developer's fault anymore.
- zaphar 4y agoIt's not the standards fault per se but that doesn't change the fact that the standard now has a reputation whether it wanted it or not.
- planede 4y agoI have some experience with libxml2. I would say DOM parsing is partly inefficient due to the many small allocations, and the library does not offer fine grained control over it. The allocator is globally replaceable, but that's not very flexible. I wished many times if I could just use an arena with a dumb allocator for a small document and just drop it when I finish with the document, but it's not very easy to do with libxml2, unless you write your own DOM parser on top of SAX.
- sgerenser 4y ago
- hermitcrab 4y ago"Welcome to Niche Software, a MicroISV based in Wellington, New Zealand. " Ahh, "MicroISV". That is a term I don't hear enough these days!(Greetings from a UK based micro MicroISV)
- revskill 4y agoJSX is standard today ?
- D13Fd 4y agoThe fact that you can use it in two ways, one of which is bad, is not really a good thing.
- gjvc 4y agoYes! The Caucho Resin server https://caucho.com/ https://caucho.com/ used / uses RelaxNG as its schema, and , amazingly flexibly, allowed for either attribute- or element-based configuration, the latter being much more pleasing to the eye in many cases. I don't think I've seen such flexibility anywhere else.
- gjvc 4y agooops! I mean "the former" -- attribute-based configuration being much more pleasing to the eye
- indymike 4y ago> What really stands out is XML Schema. It is so much more powerful and precise compared to Json Schema. As someone who was involved in making XML based international standards (HR-XML), I think what made JSON great was that it was so simple that there was initially no industry to be made out of making schema. XML had so many ways to do things a schema was needed. JSON? Not so much.
- BoppreH 4y agoThe problem is that XML is a markup language, which is entirely incompatible with the way data is usually structured in programs. Your example is simple enough, but consider the following: <root> This is some text. <type1 attributes="yes"> This is content with <i>markup</i>. </type1> <type1> Another element of the same type. </type1> <type2> And this is an element of an entirely different type. </type2> This is more text. </root> How the hell can I map that to my data model? My application data will, at worst, be a graph of class instances with named fields, containers (lists, sets, etc), and primitives (strings, ints, etc). The fact that XML has both attributes and subelements is already a huge impedance mismatch because classes have a single namespace. But what do I do with the repeated element? With the text interspaced with tags? What's the API to navigate this mess? I'm pretty sure that's why JSON won: it started from the application data model and just simplified it (no custom types, trees only). A deserialized JSON object doesn't even need an API, it's just a nested structure of built-in types found in any modern programming language.
- ivan_gammel 4y agoThis is a made-up problem that never existed in reality. On practice if you have to deal with a mix of text and elements, it is always deliberate and explicit choice which probably makes sense. In my decades long career I have never seen it, so it must be a rare case. You ask about API: XML mapping problem has been solved more than 20 years ago and standard cross-platform API exists since then. Have you ever heard of DOM? Have you ever heard of data mappers? XML Schema-based code generation? In modern Java you can even use the same mapping both for JSON and XML. There are two reasons why JSON dominates in certain applications: easier to write a small structure, browser-friendly. XML still has advantages in large datasets and schema validation.
- AtlasBarfed 4y agoDisagree. JSON can be deserialzed to hashmaps / lists with a single call that has no schema or parsing instructions. The spec unambiguously deserializes a "data document" to a data structure. XML cannot do this: - possibility of text being just ... somewhere ... it wasn't intended. - tag data vs attribute data: ambiguous - a list CAN be represented in XML, but there is no array begin/end indicator like JSON that will confirm that the tags are a list, versus some other screwy thing - finally, JSON can represent a "data document" that is just an array/list, while XML cannot do this unambiguously. It has to have a root tag. As for schema validation, that was always a hack. Schema will ultimately encounter domain-impacted information, like "is this a valid ID in our database" that a schema rule can't encode. Because JSON is so readily deserialized to, at a minimum, hashmaps and lists, it can be readily validated with code. Virtually all JSON deserialization libraries also provide the ability (in typed languages) to provide a desired type to deserialize into, and the type information of the member variables, even lists/maps, is decorated such that those can be deserialized as well. In that case, the JSON deserialization-to-type provides an automatic schema validator with no schema rules to maintain alongside the class specification. If you REALLY like XML because it kind of self-documents a bit better or stuctures better or ... well I can't really think of a reason why to use XML, but anyway I recommend YAML as a modern replacement. God I wish XPath was ported to json/yaml/toml land though. That was the bees knees as my grandma used to say.
- thadt 4y agoIt's been so long since being part of a debate cycle about whether a piece of data was an 'attribute' or an 'element' in XML. I had forgotten how much angst was eliminated when JSON came along like some kind of uncivilized philistine and just didn't have attributes.
- ivan_gammel 4y agoIn JSON everything that is not map or array is effectively an attribute. It is perfectly possible to use the same logic when defining XML schema.
- raydev 4y ago> It is so much more powerful and precise compared to Json Schema. Maybe so, but the continuing popularity of JSON, YAML, TOML, and recent competitors shows that developers (in general) prefer something that is both easily readable and editable by hand. Personal opinion of course, but I wouldn't call XML precise, I would call it the opposite because it's too flexible. The older I get, the more I think programming languages/markup languages/config languages should be opinionated and strict.