Do you hate XML? (2010) | Hacker News Reader

Do you hate XML? (2010)

sigfrid-lundberg.se

In my opinion, the reason people hate XML is because of what M signifies: it is a markup language and most of the time we don’t need a markup language. Markup languages are great for rich text documents. They are just not a good fit for representing data. The markup-nature of XML introduces unnecessary choice in whether to use an attribute or a child element to represent data; for HTML such ambiguity doesn’t actually exist but for data it does. Consider this piece of XML from the Python docs:

    <country name="Liechtenstein">
        <rank>1</rank>
        <year>2008</year>
        <gdppc>141100</gdppc>
        <neighbor name="Austria" direction="E"/>
        <neighbor name="Switzerland" direction="W"/>
    </country>

Why is the country name an attribute but not the rank? Why are all information about neighbors attributes but not children?

Furthermore parsing JSON or YAML gives you an AST that consists of the basic data types like lists and dictionaries. Parsing XML gives you an AST that requires a lot more effort to turn into data in your domain. Even on the web, very few people like to use the verbose XML DOM API like childNodes, nodeType, getElementsByTagName et al; it is basically unheard of for anyone to use it outside the web such as in Python, despite that the DOM API is in the Python standard library since forever (see https://github.com/python/cpython/blob/3.14/Lib/xml/dom/mini... for example).

YAML made me not hate XML.

Agreed. Among text based formats, nothing I hate more than YAML.

That and all the proprietary formats we had to deal with before XML came along.

Sure. Standards like EDIFACT make XML seem like a big improvement.

XML is like violence. If it’s not solving your problem, you need to use more.

Interesting point of view. JSON is also not the right thing to use in many scenarios, but it is the de-facto standard now. Maybe something like protobuf is the way to go.

Not really. In C# I use a parsing library for which I just write a class and then the library automatically serializes the JSON into an instance of that class.

I can do the same thing with XML. Of course it doesn't necessarily go that smoothly with all xml, but as long as the xml is fairly simple like a JSON document would be it's totally fine. It's only when you start to use all the features of xml that don't fit neatly into a class model that it starts to get annoying. But if JSON serves your needs then simple xml does as well. I wouldn't use it because JSON works just fine but it's not as bad as people make it seem, unless people make it really bad.

That is actually a good approach that I have also used a lot: let the parsing library handle everything including the serialization and deserialization. But if you do that, why do you care that behind the scenes it is using JSON or XML or protobuf or something else?

Because at some point you have to debug stuff. And JSON is easier to read than XML to figure out where a problem might be.

I would even go as far to say that XML may very well be better in some cases, - here you have a schema most of the time, so you can often catch e.g. schema evolution failures at compile time.

This is much less common/less standardized with json.

JSON schema exists. If you restrict yourself to a sensible subset of XML features in your XML schema, you can have a 1:1 correspondence to JSON and JSON Schema. We do that at work. Due to historical reasons we have a XSD but provide the complimentary JSON Schema to those who wish to send us JSON.

The JSON is converted on the fly to XML based on the XSD so it can be ingested by our existing XML integration. Similar with return answers, response XMLs are converted on the fly based on the XSD to JSON.

JSON endpoints validate against the JSON Schema, also generated from the XSD at runtime, XML against the XSD of course.

We had a diverse set of XSDs but didn't have to tweak them to support JSON. We used restrictions and extensions, both simple and complex, we used min/max, enums, descriptions and examples and more, so not entirely boring XSDs.

We did establish some conventions, attributes turns the child element to an object and the attributes become properies, just simple stuff like that.

This way customers can hand us what they prefer generating and ingesting, and we don't have to worry about keeping two different schemas for the same endpoint in sync.

Because SAX parsing is a thing, and the visitor pattern makes it easy to elide searches in sub-trees if an attribute does not match.

So if name == "foobar" then read; else ignore. For a 500 GiB XML file that makes a difference.

As for your other point about an "AST" (it's actually just a DOM.) That's the the benefit? And you're in for a surprise when you learn that reaching into a deeply-nested JSON structure deserialised into whatever memory format most appropriate for your pet language is also an abstract data type that you act on with getters/accessors/what-have-yous that is in all but name a DOM.

And we do have tools to deal with it: XSLT for transformation. For querying? XPath.

> Why is the country name an attribute but not the rank?

Perhaps because it's an example of what is possible in XML and how to parse it, and not, in fact, a particularly good or canonical example of XML?

I think GP’s question was rhetorical. They know it’s an example.

It's a very typical example. The real world does look like this.

So it was, in fact, designed correctly as an illustration.

Either way the context of that comment is "why does XML do this?" when in fact XML, itself, does not.

It allows both data and metadata; this is not a flaw, because it is not a pure data format.

You can choose to use those features correctly or incorrectly, and how you choose to do it is application-specific, because it is a format that is capable of producing both structured and semi-structured markup. Sometimes an ID is data; sometimes in the context of an application it is only metadata. It depends.

And that is putting aside that this complaint was used to mount a partial defence of YAML, which is one of the worst things the open source community has ever done to the world. YAML is never the answer.

> Furthermore parsing JSON or YAML gives you the basic data types like lists and dictionaries. Parsing XML gives you an AST that requires a lot more effort to turn into data in your domain.

More precisely: in XML, elements (nodes) are named/labeled. ("node-labeled graph") In JSON, keys (edges) are named. ("edge-labeled graph")

In programming, we need names for the fields in our structures (edges between objects), so JSON is a much better match than XML (which needs contortions to handle this use case -- e.g. by having nesting levels alternate between element=node and element=edge). Only in some object-oriented cases (which derived class should the deserializer construct?) do you care about node labels -- but usually that's in addition to edge labels, so a "_type" key in JSON is still easier than XML.

CSTML gets the best of both worlds https://docs.bablr.org/guides/cstml

Well, "easier" may well be "one less dimension to encode data" in this case.

Sure, this gives quite a few variations on how to serialize some data. But it's not like json's simpler approach would make data serialization universal, there are many different ways to encode the same thing.

Cardinality is the easy way to resolve this. If the data has a cardinality of 1, it should be an attribute. If cardinality > 1, it should be a child element/node.

Not sure I understand. How do you represent an object nested in another object?

It’s not easy though. When we started with html we assumed images could only have one source. It was obvious that cardinality was 1. Later we realised we could have multiple versions of the same image. With audio tags that was resolved.

I’ve come to realise that it’s almost always a mistake to assume a cardinality of 1, unless it’s something that is defined to be artificially unique like the id attribute.

Attributes are intended to hold metadata, not data. It's not the fault of the format if someone chose to use it in a poor way.

You also need to distinguish the format itself from the various libraries that may be available to parse/process it in a given language. It doesn't always make sense, even when it's an option, to let the tail wag the dog and choose a language just because it has a nice library for something.

> Furthermore parsing JSON or YAML gives you the basic data types like lists and dictionaries

Well, maybe some library for some language does that, and if that is the language you are using, and that is all you need, then I suppose you are in luck. More generally you may want to use a format like XML or JSON to hold user defined types, which rather levels the playing field since there are few good libraries for this in any language,and you may need to roll your own (been there, done that).

> It's not the fault of the format if someone chose to use it in a poor way.

Which is why we've ended up with things like WSDL which define another layer on top of XML to make it actually usable for the thing it is used for. Hence the collective exhale when JSON showed up.

Again we come back to it being a markup language.

In markup, it's usually pretty clear what is data and metadata: <font style="bold">hello world</font> and not <font><style>bold</style>hello world</font> because you don't want the word "bold" to literally appear in the document.

In structured data, the distinction is redundant.

Not always.

For example, XML itself doesn't have types, so maybe you need to use attributes to store the data type (e.g. what if you need to do to lossless JSON <-> XML conversion).

and what is the difference between <data type="dict"> and <data><type>dict</type> and <dict>?

If you use tag "type" rather than attribute "type", then you are going to clash with representing data that itself needs to use tag "type".

I hate the X and L parts too. Just because you put a URL inside doesn't make the other side understand your structure. The features that try to make it extensible actually make it less so.

I can't think of any cases XML has helped, and plenty where it's massively gotten in the way. XMPP should've been json for instance. React used something like XML in structure for JSX but didn't actually use XML, so thank goodness we didn't have to put xmlns= all over it.

Length-limited, singular and scalar pieces of data can definitely be held in attributes. It is perfectly fine to have:

     <country name="Liechtenstein" rank="1" gdppc="141100"> 
        <neighbor name="Austria" direction="E"/>
        <neighbor name="Switzerland" direction="W"/>
     <country>

XML was a good, well-intentioned idea.

The problem, IMHO, was that rampant "xml-abuse" in the naughts. ws-* standards and over-engineered garbage like SOAP ("complex object access protocol") made people loathe XML.

I did like JAXB in Java, XLST, schemas, XPATH. Never got into XSL, but it seemed like good thing too. It worked best when your tooling manipulated it for you or at least helped you in an intelligent way. Much of the hate for XML came from situations where you had to deal with someone's over-the-top-one-size-fits all schema without the benefit of tooling to at least hint you in the right direction.

It still survives in WPF and c# *.proj files. If it were just me, I would still use it for object serialization. But json is king now even though it's inferior.

It's non-trivial to implement XML parser in a secure way, many stdlib ones are insecure by default. That should just not be a thing. XML has a bunch of vulnerabilities very specific to it, XXE is the most well known one, but you also have a bunch of DoSes due to expansions and XPath injection etc.

An object serialization format should not have a bunch of footguns and vulnerability categories specific to it.

The funny thing is that JSON parsing is usually kinda unsafe in it's main target language JavaScript, and usually safe in other languages, because of the `__proto__` prototype pollution.

It's trivial to make a secure parser. The problem is that the secure parser doesn't follow the standard because the standard mandates insecurity.

SOAP seems totally in line with the XML philosophy.

Honestly, some of the worst aspects of SOAP were legacies of XML-RPC. Some of the remaining messy parts were often "yes, you can not implement that, but then if you ever need functionality X, Y, Z - you will be fucked without this complexity".

Similar to how we have DER in ASN.1.

The rest in my experience was often related to crappy "generate me XML interface from my crappy Java/.NET class" because enterprise software demands speed of development over everything else, even if that speed is taken away by meetings

I think XML's main problem is the ridiculous hype-wave that started in the late 90s. I really didn't want to see and hear XML anymore at the time. It was clear to me that it was no more and no less than a slightly awkward toolbox to build your own domain-specific language. Stupid as some of the later hype waves were, most weren't as stupid as the XML hype wave (with the notable exception of blockchain all the things).

XML is actually okay to work with, I don't mind it. XML schemas, XSLT and such are a little more... special, but also used much more rarely.

My reasons to hate XML:

- element vs attribute ambiguity

- model of the document does not fit nicely to programming model of structs, dicts and arrays

- too many complexities (entities, cdata, parser directives)

- cardinality unknown without schema (is that a single value, or an array that just happens to have one element)

- order of elements may or may not be significant depending on schema

- not really extensible if the original schema does not explicitly allow for extensibility

- some types of valid XML documents are not representable by a schema (e.g. any number of different elements in any order)

- verbosity

- namespace identifiers being URIs that may or may not be resolvable

What I want for general data exchange is JSON with comments and sane namespaces.

Edit: line wraps

JSON does data exchange ok. Protobuf does it very well. Google fumbled its ecosystem, should've focused on establishing it as an easy alternative to HTTP+JSON, instead focused on gRPC which is its own thing. Textproto is quite readable and supports comments, great for config files.

XML is so much fuss for nothing. All that xmlns uri whatever stuff and it still doesn't tell the other side how to parse it.

At least XML is hated for the wrong reasons (e.g. verbosity, esthetics) most of the time. There was for sure an era where it was overused (see Apache Cocoon from 2006 https://en.wikipedia.org/wiki/Apache_Cocoon). But XML is still a pretty good format to exchange (and store) data and make sure the data conforms to a certain schema. JSON Schema in comparison is not nearly as powerful.

1. What, in your view, are the right reasons to hate XML?

2. To me, verbosity and aesthetics seem like perfectly valid reasons to hate XML. Once you learn S expressions, XML looks disgusting. They implemented half of Common Lisp in a markup language.

> They implemented half of Common Lisp in a markup language

Come on, S expressions are just trees, they are not God's gift to humankind.. and just because a language has an AST (surprise, a tree again!) doesn't make it a lisp. I can write a C program's AST as sexprs or a Haskell program's, yet neither will be a lisp.

S expressions are just trees. XML is just trees. But S expressions are much less verbose trees. Once you see that they're both trees, then XML looks disgustingly verbose.

XSLT is what I meant by "half of common Lisp". It's probably an exaggeration, but once you can use XML to transform XML trees into other XML trees...

The right reason to hate XML would be some technical limitation or technical issues with it. But XML works quite well and is reasonable powerful. So the complaints usually boil down to: It is ugly and verbose.

To me, verbose is a technical issue.

I mean, it's also a taste issue. The verboseness is ugly. I don't like it.

But it's a technical issue. You have to parse all of that verbosity, every time you read it, which is inefficient. If you're hand-generating it, which happens in the development process, you have to get all of that verbosity right, or it doesn't work. These days nobody hand-rolls a parser, but the interface to the parser is more clumsy than it needs to be, because it mirrors the structure of XML.

XML is unfairly maligned. Yes, people bought into it too much 26 years ago, but then you would too if you had to maintain someone else's massive packed struct dumped into a file and documented in a poorly-maintained word document --- or worse, a brace of dumb IETF RFCs that contradict eachother.

I am glad that younger generations are looking at it with fresh eyes. XML is a useful format; it has its place in your toolbox. Ignore the haters.

XML wasn’t the best alternative then either. S-expressions have been around since the 50s and are better than either XML or JSON.

Younger gen here, I hate XML, and I'm probably the only one who understands it among those I work with, since at some point I was a team's expert on XMPP. I understood the whole purpose of XML deeply at some point and still wanted to remove it with bleach. Did eventually get to replace it with JSON.

Anyone else encountering something that uses XML, they'll sort it into the realm of boomer stuff that you sic Claude on and not care about how it works, like Haskell or Angular.

I’ve hated XML since 2004. The worst part about it is the tags vs attributes fights. They both do the same thing and the only difference is preference. Having two ways of doing the same thing invite and incite religious positions and cause unnecessary fighting. There should be one, opinionated way of doing things so you avoid confusion.

yeah it's not a good design to have tags have two sets of children: a Set of key-value children and then a List of tree object children.

> The worst part about it is the tags vs attributes fights. They both do the same thing and the only difference is preference.

They're not the same thing. If you look at it as the extensible markup language for documents that it is, "tags" (i.e. inner content) would be visible and "attributes" would not. If your XML document was processed by an application to convert to another type of document (PDF, etc.), and it didn't recognize a particular tag, it would be sensible for attributes to disappear, but inner content ("tags") to remain.

It's only seems like a preference thing if you look at XML as a structured data format like JSON is.

In data structure terms, attributes do allow nodes to be decorated with additional information without forcing any change on existing parsers. In JSON, this would require swapping, eg. "str" -> {"value": "str", "attrib1": "..."}.

> If you look at it as the extensible markup language for documents that it is, "tags" (i.e. inner content) would be visible and "attributes" would not.

  <input type="text" value="Is this text visible?" />

I dislike it because it failed in such a fundamental way as a way to represent a document; you cannot, in general, reliably determine what characters the bytes in an XML file represent - the best a general XML processor can do is guess.

By default XML is either UTF-8 or 16, any other encoding has to be identified either through metadata or an explicit declaration in the document itself.

If you are guessing it is because someone failed to properly store or transmit the document.

By "through metadata", you mean with some external separate mechanism unrelated to the XML spec? That's exactly the flaw of what's supposed to be a universal and general document representation.

Both UTF-8 or UTF-16 are supported, yes, but that doesn't solve the problem because XML parsers have to deal with other encodings. A document that initially looks like UTF-8 could be almost any of literally hundreds of encodings including all the common ISO 8859 encodings. Which is why XML processing/parsing code has to go through multiple phases: a "try to determine the encoding" phase (using heuristics like those described in https://www.w3.org/TR/REC-xml/#sec-guessing) and then switch to a "parsing" phase after rewinding to the start of the document.

I did some work for a bank once which were in the process of moving to using XML as the universal messaging format (message bus architecture) and this wasn't some theoretical issue - it was a genuine pain as the message sources and sinks included a bunch of machines with different native encodings including a bunch of IBM machines (EBCDIC), old Windows machines, proprietary Unices like HPUX, along with Linux, etc.

This is a well known problem with XML.

> By "through metadata", you mean with some external separate mechanism unrelated to the XML spec?

The code generating the xml text may not be aware of the final encoding used to store/transmit it and a library writing text to an encoded stream might not be aware that the text it is sending contains xml. So I would say allowing xml to be parsed using an externally specified encoding makes at least some sense.

> A document that initially looks like UTF-8 could be almost any of literally hundreds of encodings including all the common ISO 8859 encodings

Your own link shows that those "hundreds of encodings" are all based on ASCII, which is enough to get the concrete encoding from the declaration.

> and then switch to a "parsing" phase after rewinding to the start of the document.

So one call to fseek(stream, 0, SEEK_SET)?

Last year we chose XML as the basis for our document language.

It's been a good choice for designing a new language, but we've been really surprised by the poor quality of the available parsers. We figured it would be a solved problem, but we'll be writing our own at some point.

I completely agree that it is the best choice for a document language.

To the point that I have to ask: what other alternatives are there?

It's a good question. We had a previous language, JDoc, based in JSON. It covered only part of the functionality of the XML-based language and was really only for machine-machine.

We researched a bunch of others: languages like LaTeX and Typst are obvious alternatives. We also considered a super-augmented version of Markdown. Even looked at YAML.

Libxml2 segv when the input is large and the transform complicated was something of a surprise to me. Parsing xml is easy enough but I think implementing xslt is going to be a nuisance.

XML is just so much hassle to parse securely, and it is extremely difficult to get right.

Not at all, actually it is much better than JSON or YAML, which its advocates eventually had to come up with all the tooling that XML already had in place.

Schemas, comments, transformation tooling, IDE integration,....

JSON is okay most of the time, but I loath YAML.

How many Kubernetes administration headaches trace back to the need for automated systems to surgically edit YAML? It’s absurd and YAML may be the worst choice for this use case.

Recently I go to learn data ingestion pipelines configured in YAML for ETL purposes in SPARK, instead of plain SQL, oh the pain to debug anything.

Kubernetes makes me miss WebSphere 5, the version is on purpose, before the usability goodies that came up in 6.1.

Honestly I miss it. As overengineered as it was, at least we had proper tooling for it, and while there were dialects in the associated tech (e.g. XML Schema vs RELAX NG vs Schematron) it was minor compared to the wild west that JSON is to this day.

> developers must become domain experts [my emphasis] in a rich and complex space that is essentially unrelated to the application itself.

XML is a markup language, but most people that used it just needed a standard structured data format. In comes JSON which is more easily compatible with the object systems of various languages and in particular is compatible with Javascript syntax, and XML loses most of the people that used it.

As a markup language though, it seems pretty good. It's just that the amount of people that actually need an extensible markup language is much smaller.

I do hate the strictness of it. The header

  <?xml version="1.0" encoding="UTF-8"?>

should be unnecessary. For a markup language, an already-made plain-text document should already count as XML. The tags should be something you can just sprinkle as you'd like to add contextual metadata.

It will be back like vinyl.

XML should've been banned in the Geneva Convention.

Aside I love how about me is just another tag and clicking lists 3 blog posts.

On XML I don't hate. I hate wrapping my head around XSLT but that is more about my head. AI may make XSLTing more bearable as it happens? I did work with someone passionate about XSLT. Aaaand now I am doxxed.

I also thing in practice schemaless i.e. JSON or "the schema is look at the code or some logs lol" won because fuck let's face it that is more fun.

i dont hate it, the declaration kind of annoys me from time to time digging into attributes can be annoying its obviously not the best form of structured data.

json is just easier for my brain at this point if it needs to go over http, but ive seen some pretty... poorly designed json structures.

csv is always a good time. love when i can just plop important data into a table and query away

I don't hate it but I definitely don't like it.

I write a lot of html already I don't need xml too in my life.

Every time XML comes up, I feel obligated to share my opinion (I too wrote XML a the turn of the millennium and have seen it become and still witness on occasion it being excommunicated).

XML is verbose and therefore uglier than it ought to be. I think most of the haters hate it for that alone -- there's not much else to hate because you don't have to deal with the rest, it's not really imposed on you unless you really have to deal with someone else's XML application.

What do I mean? Well, the brackets thing and the necessity to repeat name of every element twice, in correct (LIFO, last in first out) order, isn't great, admittedly.

What XML has that the dev-bro alternatives that have flooded the void XML left since, haven't gotten and thus see being reinvented, are: namespaces, attributes and interop using the former two. Sure you can write JSON and YAML (the latter deservingly being incredibly hard to parse correctly -- they tried to design a better XML but failed IMO) -- but these suck as meta-languages because there's not much "meta" there. JSON, for example, allows you create properties and has a few types (kind of more than XML, really) but it leaves semantics up to you and namespaces are up to you to re-invent, poorly. If you think I am stretching the argument, see if you can represent an HTML document (no, not Markdown) with a JSON file.

YAML is a similar story, albeit with a few cool things like aliases. I think it's a better attempt to give the world a better XML, but the jury is still out on that one.

The killer thing with XML, for better and for worse, was plethora of tools to work with it. I wrote a fair share of XSLT documents to transform data, back when there was momentum in XHTML, for example. XSLT barely supports JSON and it's not pretty. XPath cannot natively understand YAML -- unless you convert it to XML which I guess re-animates XML as some sort of Frankenstein's monster. And even if it were a [pretty] monster, dealing with intermediate representation for the kind of purpose, is a can of worms all of its own.

Ironically nobody seems to hate HTML 5, seemingly. Or React basically turned it into a greasy cogwheel nobody needs to look at. Because if you look at it, it's in my opinion an abomination even compared to XML (unpopular opinion) -- the parser is quirky and behaviour is defined by the standard per element type (i.e. some elements need a closing tag and some do not, and what happens if you forget a closing tag is element-specific; care to remember the set of rules to ensure your document renders to your liking?). It has no namespaces but it has "custom elements" which require a dash in the name as poor' man's namespaces and you can't omit one, and now we have a Web of `x-spinner` and `x-carousel` because it turns out everyone rightfully wanted default namespace but didn't get one. Anyway, it's all plumbing, right -- the idea of _writing_ HTML has largely come and gone us by. And I am digressing.

I don't like HTML5 and to this day I don't understand what was actually gained by dropping XHTML.

Not having the page break because of a small mistake. Though I did get pretty good at writing XHTML, and strictness is a blessing in certain cases.

Fail fast is a feature, not a bug. It's much better to get clear and actionable feedback rather than the page silently rendering incorrectly in some subtle manner.

XHTML was dropped because it wasn’t backwards compatible, and it was too strict in its syntax. Minor syntax errors that could be automatically corrected by the browser turned into full page errors.

Meanwhile valid XHTML like having custom elements as table children, in HTML gets silently "corrected" to an malformed document.

I'd much rather have the stricter syntax parsing of XML, vs the complex and outdated structural correction rules of HTML.

I think this is _the_ most popular criticism of HTML 5 vs. XML, that I have seen mentioned. Which is telling, quite frankly. It makes me think that the powers that be that pushed HTML 5 really had a different agenda than what they purported to have. We might never know the politics behind it, but I struggle to comprehend the wisdom of a decision to basically overhaul the lingua de franca of the Web because "XML parsing is hard!" then replacing it with HTML 5 and its peculiar "context sensitive grammar" noone ever remembers or bothers to look up, and the other features like custom elements (with the latter, by the way, in the spirit of "let's just ship it and see", they kind of foundered with the sub-classing there -- Apple rightfully refuses to implement some of Custom Elements API because it flies in the face of Liskov's Substitution Principle).

Can you think of a minor syntax error example that you believe should be corrected by the browser, and better than the author would (had the Web browser notified them early -- by aborting rendering as was the case with XML)?

There's a bit of irony with the fact that HTML 4 which _did_ have browser "correct" errors (albeit in non-standardised manner) _was_ what motivated XML in the first place -- it's just that in light of the wildly different correction behaviour between Netscape Navigator, Internet Explorer, etc, they decided on a pragmatic solution -- abort and tell author, like a C/C++ compiler. The latter can also correct syntax errors, strictly speaking -- but you'd be hard pressed to find a programmer that would seriously consider letting the compiler do that. Why HTML should be different?

Say you forgot a `</p>` and then comes a `<li>` -- since `li` elements cannot be children of paragraph elements, I guess the Web browser, in compliance with HTML 5 for example, could mandate that the paragraph ends just before the `<li>`, meaning it behaves as if there _was_ a `</p>` before the former, _and_ also inserts... what, a `<ul>`? Why not `ol`, then? This heuristics is messy, if only because the Web browser doesn't have enough context to _know_ what the author wants, and can't assume a single kind of omission. And HTML 5 simply defines some default behaviour, handwaving the problem, but the truth is no HTML 5 authors -- myself included (I have been writing HTML in one [proto-]form or another since 1994) -- ever remember what those rules _are_.

> Well, the brackets thing and the necessity to repeat name of every element twice,

As a document format, it's supposed to be hand-written by humans. If you have paragraphs between the opening tag and closing tag, it makes sense to let the reader know what they're seeing the closing of.

After deciding you do want to repeat the element name, the angle brackets make more sense. Otherwise, you can have a syntax like LaTeX's.

What do you think of CSTML? It's my attempt to heal the rift between XML and HTML5, as well as solving all the problems that made XML feel onerous to use... https://docs.bablr.org/guides/cstml

It's simple to parse like JSON, it has namespaces like XML (but better), and it doesn't require you to repeat the name of every element twice.

I looked at CSTML, and frankly, it looks like any other improvement that upon first glance may seem like definite improvement, but the trouble with these dialects or ideas is that it's not the format that's hard to incorporate -- even after you prove it is sound (undesirable parsing ambiguities can something show themselves _after_ you wrote a parser to verify the language grammar etc), but pushing for adoption is. XML didn't die only because it was verbose, it died because the people who may have been convinced of some of the featured really disliked by everyone else, refused to budge -- perhaps they thought that repeating the tag's name is a good thing because it forces one to be diligent or whatever * points to some research paper that supposedly proves repeating text improves accuracy *. It's the equivalent of doubling down when opposed. So XML basically became more XML the more criticism piled up, and as it ossified it died. CSTML, as likely much of anything else that aims at replacing SGML/XML/HTML, is like projects -- ideas are cheap, going through with it is hard. Before CSTML is a long path of adoption, and today with HTML 5, it's even more narrow unless Google, for one, suddenly decides it's the best thing since `<parsed-bread>` (closing tag is omissable).

I think some straightforward YAML schema for representing HTML 5, may have more traction because both are existing languages so not much extra tooling would be required. I could for instance write my Web blog in YAML that is unambigously and simply compiled into HTML 5 (without sacrificing a _single feature_ of the latter), so I don't have to actually type HTML (5). Not everyone uses React or JSX or what have you, and Markdown implementations in practice are often lacking for truly rich blog articles. Then again, if you have a blog article with interactice diagrams, sliders and ad-hoc questionnaires, _XML_ (or a YAML representation thereof, for much the same reason as outlined earlier) _is_ IMO a good language _in form_ -- I have used XSLT with good effect to just stick to a domain-specific language for my blog articles, and have a single XSL stylesheet render uniform HTML page linked to a CSS stylesheet that was basically a posterchild for the coveted content-presentation separation in practice.

I've taken care of the parsing ambiguities. There were some, and yeah they took me a while to find. I've been working for a while though : )

Also completely with you on wanting a language I can use to losslessly write HTML, and CSTML does that too. That docs page on CSTML is written in CSTML for example: https://github.com/bablr-lang/bablr-docs/blob/trunk/src/cont...

I also think the path to adoption for CSTML is eased considerably by the fact that most CSTML documents will be produced as parser or WYSIWYG editor output rather than hand-written. And yeah, the whole world of XSLT opens back up again with this tech. I loved the idea behind XSLT. It was a great idea. It created a much richer semantic internet, and then let visual presentation be a concern purely secondary to semantics.

The one good feature of HTML 5 was the introduction of boolean attributes. It's a feature XML could and should adopt.

The whole handling of custom elements was fumbled beyond belief. The HTML spec is a disaster particularly it's parsing rules the complexity of which is used as excuse by HTML spec authors not to improve the language.

XHTML was a better path.

I think the reason we don't see too many people complaining about HTML 5 is because not many web programmers use it directly, most are using JSX.

I agree we shouldn't have thrown the baby out with the bathwater -- and it's not like _strictness_ was not in XML's spirit, so your usual suspects for primitive types -- numbers and booleans, to name a few -- _could_ have been an improvement along the XML's path of evolution. But something tells me that these features only open a door to more features that are needed. The bounds on what constitutes the [sufficient] set of fundamental types, is a hard problem to solve, especially if it cannot be extended through itself (composite/compound types). XML had not anything but strings for attribute type, but that also made it simple and kept it away from the domain of type theory and parsing more than it already had to have parsed. So I am undecided, but I liked the "one good feature of HTML 5" part of your comment, so I took your bait ;-)

XHTML, as has been _repeatedly_ mentioned by multiple people -- a thing that comes again and again -- at least was _strict_ in that your malformed document told you _early_ (or, rather, a compliant XML user agent did, like your Web browser), where with HTML it's your users that find out, except they have no clue what's going on -- they know even less about HTML 5 parser than the author does, staring at something that should have been a list item but becomes a table cell element or some such.

If HTML 5 is indeed not even used directly, that makes the argument for the _stricter_ format like XML-based XHTML even more attractive -- machines do much better with strict bounds than humans do, so if humans aren't writing HTML, then it feels like we've been sold on the wrong premise, even if retrospectively.

Boolean attributes are less about types and more about syntax convenience IMO, even HTML treats them as empty strings. <tag attr> is a shorthand for <tag attr="">, which then in your program you can decide if some attributes should handle empty strings as a truethy value. Some cases like <person name> the program would still make sense to treat it as an empty string.

> If HTML 5 is indeed not even used directly, that makes the argument for the _stricter_ format like XML-based XHTML even more attractive

True however those who control the HTML spec are unlikely to let it go. Since XHTML has been treated as effectively deprecated some feature like incremental document streaming do not work in XHTML, this makes it unlikely for libraries that abstract away HTML to adopt XHTML as a target.

Right, if what you mean is making the `=""` optional, then it seems even more attractive than types, I admit. You'd have to amend the XML grammar to see if making the `=""` optional introduces problematic (for e.g. the reference parser) ambiguities that weren't there before. From the looks of it / intuitively it doesn't seem to be the case, but with a language that's deployed in a gazillion places such small changes rightfully warrant new major revision, which would be XML 2, I guess. Which would have wide ramifications, I imagine. Which brings me to W3C....

> True however those who control the HTML spec are unlikely to let it go.

Like I said in another comment, I believe XHTML was axed because it stepped on _someone_'s toes. I suspect it had to do with W3C being understaffed and criticised for being too slow at the time -- by most of the industry, and most of it deservingly -- and WHATWG (with Google co-authoring their standards) stepping in as the authority on all things Web, and somewhere between the two XHTML was used as the proverbial fall guy. Speculation, of course -- but a lot of good, useful work was thrown out the window with XHTML. Not the first time it happens, of course, but this was the Web we're talking about, not Adobe's product portfolio.

I've heard the "streaming" argument before, by the way -- it keeps being mentioned (probably because it was one of the official reasons for the transition to HTML 5), but I think it's a "ruse" -- nothing about XHTML in practice prohibits an agent from progressively rendering an XHTML document, and if something really did, in W3C's writing for instance, then all they needed to do is relax that requirement because again -- there's plenty of hierarchical data formats with strict rules that by their very nature don't preclude parsing (or semantic analysis / rendering) done in streaming fashion.

XML is ok, the problem IMO is that the way some people use(d) it is utterly unhinged.

So a return value that could have easily been two lined of text is now a nested demon of XML. The complexity isn't what that application does, the complexity is in how it returns the values.

Another good one is to use XML when something else would have made things simpler, e.g. for a config file where you could easily have used a .ini or a .toml file.

Or you have an application that tries to so generic that the definition for a simple use case is a whopping 5MB XML file. Cool. When I feel writing a config for your application is harder than programming the whole thing yourself you have really made it. /s

Reply on news.ycombinator.com