Good idea. You would have to edit your annotation layer in case the text data changes though.

Now you've lost human editability/readability and could just as well encode that in a non-XML format.

It seems klutzy and yet fully in the spirit of XML.

crafty, but for your consideration: that places the burden upon every library author to be "accounting accurate" to any edits, and the only way anyone would know that it's not correct is to visually inspect the output text

also, as I get older I have a deeper and deeper appreciation that "offset" and "text" are words that are fraught with peril

Yjs isn’t a document structure is it? It seems to be a library for collaborative editing, but I’m not seeing something suitable for marking up a document, or am I missing something obvious?

>In all seriousness I get the idea behind XML

followed by

>and I have used a couple of SOAP services which were absolutely brilliant

makes me doubt the first part of the statement.

If I were to guess what it means is you understand the point of SOAP, and also understand the limitations and problems especially as it relates to uses of XSD in SOAP and the various stack of Web Service specs, but you probably have not had much experience with non-XSD based validation of XML, you do not have any experience with document formats as opposed to data formats, you probably are not familiar with larger international standards like UBL, and not familiar with XML formats that are not so much data or document oriented - SVG, XSL-FO (which admittedly sucks more than is reasonable), GraphML and so forth...

A lot of the commenters here are standing up for the value of XML, and I'm not actually with this comment, there are a lot of benefits for using JSON especially when you are using JavaScript all over the place. But saying XML sucks because XSD and SOAP sucks indicates a potential lack of knowledge about the whole subject (perhaps only caused by infelicitous phrasing)

>I feel like I'm being punished by the stupid people who make me use it

What's the use-case and what alternative would you prefer?

I'd extend this "X developers are mostly self-taught" onto all of computer development. They say, "Every developer Of a Certain Age's first programming language was BASIC" and my experience of (eventually) getting a CS degree is that there is the expectation of students to already know how to do the thing that they are trying to teach; a certain level of "self taught" is expected. To that end, I can see how in The Age of Teh Internets that the standard of self taught has moved of from BASIC to HTML/CSS/JS (or Unity or whatever sparked the young mind's attention). --- What I'm not certain of is that "self taught" means that work will be duplicated because the self taught developer doesn't know the technology that exists. I think that someone who is extremely online will very likely be more abreast of what technologies exist. I think that a formal education is better at establishing what the fundamentals underlying a programing method or paradigm... but not necessarily at exposing new programmers to what the state-of-the-art is.

I prefer JSON's strictness. A Boolean cannot be confused for a string.

In yaml:

    country: no

Now your country is Boolean(false)

Now, I still prefer yaml overall.

Also, I hate that GitHub actions don't support anchors.

There’s always JSON5

YAML is a fine implementation of JSON with comments.

XML is only concerned with whether a document is well-formed, not its conformity to a given schema. Schemas like XSD, DTD, etc can be plugged in later. Many systems just have an ad hoc schema.

> At least with JSON and HTML, you don't need a separate definition file for basic, primitive data types.

Unless I’m missing your meaning, this seems like an apples-to-oranges comparison. HTML is not a general-purpose format like JSON. It’s a very complicated document format that is validated with reference to an external spec.

I think XML is a great fit for a document format that can become arbitrarily complex yet still easy to author and validate. It’s obviously a really poor fit for a wire transport protocol.

How is your example any better in JSON? { some: true, someOther: 1, another: "true" }

> The absolute worst bit of XML is the confused implementations. What should be an attribute on a tag, and what should go between tags?

XML is a language for marking up text. SVG uses attributes for all vector data, because the vector points are not meant to be presented to a user as raw data.

If I embed a SVG into a XHTML document and the browser does not understand SVG, the text within the graphic is still presented to the user.

> Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently:

This is not a responsibility of XML, which deals in a common well-formed markup format for various document format.

It sounds like you are dealing with a tool that has defined an XML-based data interchange format, and that they may have inconsistent tooling for their format.

> you don't need a separate definition file for basic, primitive data types.

unless you need something different from JavaScript primitive data types.

For example integers.

Or null means nothing to you.

Or you want a faithful representation of input

   Welcome to Node.js v20.5.1.
   Type ".help" for more information.
   > JSON.stringify(undefined)
   undefined

   > JSON.stringify([undefined])
   '[null]'

but then

   jq "." <<< "[null]"     
   [
     null
   ]
   
   jq "." <<< "undefined"
   parse error: Invalid numeric literal at line 2, column 0

>> What should be an attribute on a tag, and what should go between tags?

Are you ok with <a href="..">link</a>?

That was kind of my original point, people are fine with html but don't like XML. I think the real reason people don't like XML is it reminds them of Steve Ballmer.

> What should be an attribute on a tag, and what should go between tags?

I think a good rule of thumb is that attributes are for key/value pairs that are probably not user-visible and definitely not directly user-editable.

Carried to a logical conclusion, this would simplify the auto-creation of form GUIs.

> JSON just says do “\0” and calls it a day

nope

   jq "." <<< "\0"
   parse error: Invalid numeric literal at line 2, column 0

   jq "." <<< '{"name": "\0"}'
   parse error: Invalid escape at line 1, column 13

maybe you mean null, which has a lot of different issues though.

   jq "." <<< "null"          
   null

   jq "." <<< '{"name": null}'
   {
     "name": null
   }

Try using UTF-8 encoding for XML, and your problems with zero byte encoding will go away.

Your understanding of "easier" is oversimplified to the point that it's wrong. It's easier to do the wrong thing in JSON, it's harder to do the right thing in JSON (compared to XML).

JSON is a poorly thought-out format. It's problems become progressively more difficult to deal with the more you expect of your program.

There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far from simple in that later case.

I.e. learning about namespaces would take a programmer couple of hours, including a foosball match and a coffee break, but working around JSONs bad decisions when it comes to number serialization or sequence serialization will probably take days in the best case, with a side-effect that this work will most likely have to be done on an existing product after a customer complained about corrupting or losing their data...

Neither did XML originally. XML schema was sort of bolted on via some conventions of defining a schema in the root element. The XML 1.0 spec doesn't mention those. XML Schema is a separate standard that came later. Likewise namespaces are a separate specification as well and not part of the XML specification.

The XML specification does have Document Type Definitions (DTD), which were sort of inherited from SGML. This is an optional declaration with its own syntax that defines a DTD. I don't think they were that widely used. XMl Schema started out as an attempt to redefine those in XML.

The nice thing with XML Schema was that you could usually ignore them and just use them as documentation of stuff that you might find in a document. Typically, schema urls wouldn't even resolve and throw a 404 instead. More often than not actually. My go-to tool was xpath in those days. Just ignore the schema and cherry pick what comes back using xpath. Usually not that hard.

The culture around Json is that it emerged out of dynamic language communities (Javascript, Ruby, Python, etc.) with a long tradition of not annotating things with types and a natural aversion against using schemas when they are not needed. Also, they had the benefit of hindsight and weren't looking to rebuild the web services specs on top of json but were actively trying to get away from that.

Yeah, culture is a big one. See dotnet vs java. The latter picked up many of c# feature over the years but is still much more verbose, e.g. because their developers still abhor var

Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? So what if it's hard? -- Spend an hour with the reference document, and your problems will go away.

In the days when XML was popular I've been more active in several Web forums that helped novice users with particular technology (and that included XML). Not a single confusion about XML namespaces came from someone who read the reference. Quoting the reference would be also a very efficient way to clear the confusion.

Bottom line: it's not a problem worth mentioning. In the grand scheme of things an hour you'd have to spend reading the specification is a drop in a bucket compared to all the time you'd have to work with XML. It's a fixed-size effort that you have make once. Compare this to having to deal with bad "number" serialization that you have to deal in JSON every time in a new program that deals with JSON.

I manage a team of reporting analysts who look at XSLT transforms all day. None of them have programming backgrounds and they have never found XML namespaces to be a problem.

If these are the sort of questions that are tripping you up, just use <foo>something</foo> for everything.

Isn't this very easy ? Short, Succinct and a Simple No-frills string ? Put it in the attribute. Big, Long and Arbitrary Length Data ? Put it in the content of the element. Now gimme money.