JSON5 Data Interchange Format

  "normal string can contain ' "
  r#" raw string can contain " ' "#
  r###" if for some reason you need to write "#  "###

XML Schema were supposed to fix all the problems of DTDs, but they don't support unordered content, and have a host of their own problems. XML Schema are typically external XML documents referenced by an xsi:schemaLocation attribute, but apparently you can embed them too. But I don't know if that's a common practice, since it's a pretty bad idea for a lot of reasons:

https://www.herongyang.com/XML/XSD-Statements-Embedded-in-XM...

You raise a good point that it's a bad idea to embed schemas in documents, or even references to schemas in documents, because, as James Clark points out, magic schema attributes in documents (like xsi:schemaLocation) pre-suppose that there can be only one way of validating a document, they create security and interoperability problems, and it infects documents with the namespace of the grammar that you're using to validate them, when documents shouldn't depended on such knowledge, and be forced to include hot messes of namespace attributes like:

http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0... http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">

Schema Wars: XML Schema vs. RELAX NG (1/2) - exploring XML:

https://web.archive.org/web/20190403171512/http://webreferen...

>James Clark, leader of the technical committee at OASIS for RELAX NG, and author of one of the first XML parsers, recently described the problems of the XML Schema language in a newsgroup posting: [...]

>7) Magic schema attributes in documents

>W3C XML Schema provides the xsi:schemaLocation attribute, which allows an XML document instance to indicate the schema that should be used to validate the document. This creates problems with security (the destination might have changed or tampered with), interoperability (use of schemaLocation is optional) and "purity" of schema definition: There is no way to prevent the document containing magic xsi:* attributes, so the use of W3C XML Schema "infects" the grammar you are defining.

Here's more of what he has to say about JSON in his blog post "XML vs the Web":

https://blog.jclark.com/2010/11/xml-vs-web_24.html

>[...] From this perspective, my reaction to JSON is a combination of "Yay" and "Sigh".

>It's "Yay", because for important use cases JSON is dramatically better than XML. In particular, JSON shines as a programming language-independent representation of typical programming language data structures. This is an incredibly important use case and it would be hard to overstate how appallingly bad XML is for this. The fundamental problem is the mismatch between programming language data structures and the XML element/attribute data model of elements. This leaves the developer with three choices, all unappetising:

>- live with an inconvenient element/attribute representation of the data;

>- descend into XML Schema hell in the company of your favourite data binding tool;

>- write reams of code to convert the XML into a convenient data structure.

>By contrast with JSON, especially with a dynamic programming language, you can get a reasonable in-memory representation just by calling a library function. [...]

>There's a bigger point that I want to make here, and it's about the relationship between XML and the Web. When we started out doing XML, a big part of the vision was about bridging the gap from the SGML world (complex, sophisticated, partly academic, partly big enterprise) to the Web, about making the value that we saw in SGML accessible to a broader audience by cutting out all the cruft. In the beginning XML did succeed in this respect. But this vision seems to have been lost sight of over time to the point where there's a gulf between the XML community and the broader Web developer community; all the stuff that's been piled on top of XML, together with the huge advances in the Web world in HTML5, JSON and JavaScript, have combined to make XML be perceived as an overly complex, enterprisey technology, which doesn't bring any value to the average Web developer.

>This is not a good thing for either community (and it's why part of my reaction to JSON is "Sigh"). XML misses out by not having the innovation, enthusiasm and traction that the Web developer community brings with it, and the Web developer community misses out by not being able to take advantage of the powerful and convenient technologies that have been built on top of XML over the last decade.

>So what's the way forward? I think the Web community has spoken, and it's clear that what it wants is HTML5, JavaScript and JSON. XML isn't going away but I see it being less and less a Web technology; it won't be something that you send over the wire on the public Web, but just one of many technologies that are used on the server to manage and generate what you do send over the wire.

>In the short-term, I think the challenge is how to make HTML5 play more nicely with XML. In the longer term, I think the challenge is how to use our collective experience from building the XML stack to create technologies that work natively with HTML, JSON and JavaScript, and that bring to the broader Web developer community some of the good aspects of the modern XML development experience.