Of course. The problem with that approach is that every value becomes a string with no hint about which type it should be converted to. In comparison JSON has - at least - basic types.
There are more ways to type (at schema and inline) and more types (see the common XSD types) available OOB in XML than JSON could ever have. Then we can introduce custom types. JSON looks rather impoverished in comparison.
Many people "love yaml" and "hate XML" but never dealt with XSD, so they don't even realize what they're talking about syntax instead of functionality.
Admittedly, XML isn't the most pleasant syntax to interact with by hand.
XML syntax is fine so long as you're using a proper IDE. I manage a team of reporting analysts and all of them come from Business Analyst or Accountancy backgrounds; they write and maintain XSLT transforms just fine, once they spend a day or two getting used to IntelliJ IDEA.
XML was a great idea. At some point in the early naughts, however, XML-abuse became rampant-- too many crappy tools, too many half-assed attempts at putting square pegs into round holes. It didn't help that XML got inextricably associated with those horrible over-complicated ws-* standards that ended up sending Russian novel-sized "hello world" information exchanges.
The main idea, however, was wonderful. An information exchange format (xml itself), a way to define schemas (xsd), a transformation language (xslt), and stylesheets (xsl?). I kind of miss it.
There's also XQuery for transformations and XSD/RelaxNG for schemas, the whole combination of XML database, WYSIWYG (via XSLT) XML editor and output transformations is very powerful, every journal we published and every site we ran at the British Medical Journal was generated that way.
I miss XSLT every time I see megabytes of JavaScript converting some JSON into a soup of HTML to display in browsers. A bunch of JavaScript with a bunch of overwrought "components" is serving as a very complicated templating system.
A lot of really stupid JavaScript could be done fairly easily with XSLT natively inside a browser engine. An XML document can point to its own XSL(s) so get rendered to the appropriate delivery format or just used directly as data.
I don't miss it. I had several projects where it seemed like a good idea. I pushed it as a good idea. I really wanted it to work. Some developers (usually the sharper bulbs) got it. A lot of developers really struggled with it. Especially the folks who were 'front end' developers. Even in the 2000's, when everything was trying to go XML, staffing those roles was hard.
Tooling was XSLT's Achilles heel. Too many tools had no or poor XSLT support. What's confusing to me is a lot of the JavaScript templating today has equally bad tooling yet everyone's in love with it.
The lack of tooling for XSLT and modern JavaScript stuff are on different sides of the adoption curve. XSLT lacked tooling on the upside of the curve so it never hit critical mass. Its other problems could have been solved had it hit critical mass and seen wider adoption.
> Many people "love yaml" and "hate XML" but never dealt with XSD, so they don't even realize what they're talking about syntax instead of functionality.
No, I'm pretty sure that if they have only used XML syntax as a data rep and not XML-associated tooling like XSD, they are quite aware that when thet say they hate XML they are talking about syntax.
OTOH. I am surprised at the number of people that seem to thing “has a schema language that can be used to specify structure beyond just the basic raw language” distinguishes XML from other data representation languages.
Or, more generally, the way that “if you don’t like XML, maybe your problem is you aren’t using enough of it” has become an edgy contrarian position rather than steretypical establishment enterprise consultant thing it was 15 or so years ago.
The quotes in XML don't make it a string; in the XML schema you can specify the type (and so much more). JSON has a lot of benefits but it absolutely loses this particular comparison. XML schemas will give you all the type information and automatic validation you can swallow. Typing in XML is far richer than in JSON. There's even a date type!
> The quotes in XML don’t make it a string; in the XML schema you can specify the type (and so much more). JSON has a lot of benefits but it absolutely loses this particular comparison.
JSON, like XML, has several schema languages, which have widely-available libraries for generating host language typings, validation, etc.
> Typing in XML is far richer than in JSON. There’s even a date type!
JSON Type Definition has timestamp, JSON Schema has date, date-time, time, and duration.
The nice thing about XML being an extensible markup language is that schemas (and metadata like xsi:type) could be easily written inline, making the document fully self-contained.
I haven't personally tried such a stunt, but I'd bet it's possible to do that with JSON Schema, too, if the schema resolver tolerates the same self-references style in `$schema`. My experience with the tooling is "lol, yeah right" but shrug seems reasonable
{
"$schema": "#/$theSchema",
"$theSchema": {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "MySchema",
"type": "object",
"properties": {
"productId": {
"description": "The unique identifier for a product",
"type": "integer"
},
"productName": {
"description": "Name of the product",
"type": "string"
},
"price": {
"description": "The price of the product",
"type": "number",
"exclusiveMinimum": 0
}
}
},
"productId": 1,
"productName": "An ice sculpture",
"price": 12.50
}
JSON Schemas exist too. The most common being the eponymously named type: https://json-schema.org/
I've seen JSON schemas describe things like date types and plenty more. If you are including schema metadata alongside XML, then for a fair fight you can include JSON schemas, too.
You mean "markup" vs. "content." At least, such was the original intent: you store what is considered data as content, and metadata of any sort as markup. In many use cases, however, this distinction is now ignored or simply non-existent. One other "abuse" of XML as a structured representation of data is to embed a "foreign" (i.e. non-XML) syntax, like in the above example of rightAscension (which is not the worst example, to be fair).
There is none. In general, the main difference is that elements are all ordered wrt each other, while attributes are not. This ought to make the choice simple, except that attributes also cannot contain nested data structures.
A particularly unusual take is to ignore the difference and allow either attributes or child elements as different ways to do the same thing. This is what XAML does; e.g. this:
There is for user-viewable markup-enhanced documents, like SVG and HTML - which is pretty much what you experience with SVG and HTML authorship by hand.
If data should be presented to the user by a user agent that doesn't understand extensions to the markup, it should be using text nodes.
If it is a modification to a subset of a block of text, such as emphasizing a word, it should be a new element.
If it is a block of semantic metadata, you would structure that as a hierarchy of elements with attributes.
Otherwise, it is usually an attribute on an existing element.
SVG is a bit of a zany format in XML because so much of the content is points or encoded data, which get stuffed in some truly epic attributes.
XML wasn't really made for pure data formats, even though shoehorning that in was the majority of the market's effort.
I'd say if it's for general data exchange, I'd shy away from attributes as much as possible. Not all tools handle them well, and XML novices can get confused about their usage.
Using plain tags is so obvious that just about anyone can get it, and in my experience there's no real advantage to using attributes.
At least that's my experience at work, where we use XML as our primary integration format for others that want to deliver data to our system. When going through with a new customer, the few attributes we have almost always cause some kind of issue or misunderstanding.
I think that if you are encoding data, like your example, you should not use attributes, attributes are best used when you are using xml in it's text markup role.
In the text markup role tags are like functions and the attributes are parameters to the functions. but in the data encoding role the attributes are another redundant key value store and you end up with a confusing mix where some of your kv's are in the tag and some are in the attributes and it is a bit of a mess.
In the parent's example, every value is in the attributes. Tags only serve as objects that contain those values, and never have "content" of their own. This style might not have been the original intent of XML, but at least it's consistent and easily readable.
The parent example was remarkably consistent, far from the worst I have seen however...
There is a star tag(presumably a list of star tags) each of which contains a single position tag. The star tag is is full of attributes, and the position tag is full of attributes, now you have a complicated(not that complicated, hyperbola is for arguments sake) access method where you need to do different things based on what data you want out of the structure. Why was the position tag not an attribute? What happens when you want to encode the rightAscension, and declination, they will get their own tag, in fact they probably just should have tagged everything in the first place and avoided attributes.
If going in this direction, I’d want justification for position and age still being separate elements. Elements are clearly suitable or necessary when you want multiple values, order-sensitivity, or to contain something other than a single text value. But that’s not the case here, and I find “hierarchical structure” or “property grouping” to be weak justification.
Interesting thing about the position coordinates, is that the position really needs an "epoch" metadata attribute, like "2000" or "2050", because they are relative to the equinox which moves over the years. So maybe the fact that this kind of thing can rear its head unexpectedly might be an argument for favoring separate elements to group fields? If that new attribute were thrown in with the other attributes of "star" it looks like it qualifies the star, but it only really qualifies the coordinates.
I was downvoted a bit to start, which I found interesting. The only people I've met who like yaml are a) its authors, or b) people who have done very little with yaml.
No one is forcing you to create verbose tag/attribute names.
If we are authoring content that we expect to last a few decades, markup is the proven engineering choice. It used to be sigil markup $1, $x, @@p etc., and other proprietary markup. SGML came and introduced DTDs, entities, parsing etc.,
DocBook format is pretty good for technical manuals. They pretty much covered 98% of the use cases for technical books. It would be foolish to invent a different format (using say JSON representation or some other proprietary format) for those use cases.
SGML grew too complex and then came XML in the late 90s and took off when SOAP started gaining traction for web services in the early '00s.
Unfortunately, XML almost went the SGML way on complexity with the addition of namespaces, multiple schema languages etc., But, we can never fault XML for its expressivity. There is also a good tooling available due to the work of many standardization workgroups and browser/vendor support.
If you choose to archive content using XML, you can be guaranteed that you can parse it 20-30 years later since XML is a simple format (if you use a simple subset of features).
I mean the example given with the star looks fine to me? Crucially it's not whitespace sensitive. YAML is a terrible terrible thing and yet another place we've collectively lost the plot.
I get baited into these discussion all the time, but I'll point out that since YAML is as superset of JSON you're free to keep using JSON if you prefer it. But let's just be real that omitting the `"` everywhere is a clearer separation between content and encoding, and then representing multi-line strings is hands-down easier in yaml than JSON
But I don't think anyone is arguing that it's completely useless.
It just hasn't earned it's current privileged position in the computing world. It got there on the coattail of the obscene wave of hype around the turn of the century.
So it has a way to go as it slowly falls back to its rightful place.
I like XML. It works well, typed and reliable, supported everywhere, great IDE support.
I don't have much experience with JSON schemas, but what they failed to work when I tried one time.
JSON schemas are modeled closely after XML schemas. (I wrote a fair amount of both.)
I wonder when XSLT will be re-invented and applied to JSON and YAML. (XSLT was a bit of a miracle: a pure functional language adopted by a significant chunk of non-CS community in early 2000s. The syntax forced by XML sucked though. YAML can do better!)
> JSON schemas are modeled closely after XML schemas.
Are you talking specifically about XSD and JSONSchema? If so I don't think this is really true. Pretty sure the original authors of JSONSchema didn't pay much attention to XSD.
I don't know if they were looking at XSD, but I did write an XSD to JSON Schema[1] converter in an afternoon which does an almost perfect 1:1 mapping of a non-trivial XSD, including choice elements, basic restrictions etc.
So for a lot of XSD's I'd say JSON Schema is effectively very close.
Sadly, tooling for the latest JSON Schema (which is required for choice elements IIRC) is lacking, Swagger UI for example does not work well with it for example.
That I haven't considered, given that at our work we had a bunch of XSD's and wanted to expand our integration point to accept JSON.
I don't see any big issues with doing it in reverse for a subset of JSON Schema.
What I haven't looked at is how large that subset would be. That is, if JSON Schema contains things that aren't possible to represent in XSD.
For example, JSON Schema allows for some extensive conditional sub-schema logic. I used the "oneOf" to represent a XSD choice element, however JSON Schema also allows for such things as "if..then..else", which as a self-taught non-expert on XSD's I'm not sure how would map to XSD on a Saturday morning.
Of course, there are things in XSD which can't be represented in JSON Schema either, I'm sure it's easy to come up with something that doesn't map. But from the typical XSD's I've seen and the ones we had in our company, the mapping could be done with just a single special-case.
Given the lack of tooling around JSON Schema, my workflow now is to create/update the XSD and regenerate the JSON Schema.
I‘m currently working on yanking a bit of XSLT out and reimplementing it in procedural DOM code—currently as in I have spent the last month on this, and hope to have it in a PR tomorrow. I share your stated preference for pure functions, and their accessibility to people who aren’t explicitly programmers, and I share your implied preference for declarative programming to achieve that. Unfortunately my specific use case needs at least to become more procedural before I can take it further, but I’ve at least structured the code so it’s adaptable to pure functions in the future.
I really don’t think YAML and its own terse but ambiguous rules are better suited. The problem I’ve found in XSLT during this effort, and in YAML in the past, is there’s no debugging story that isn’t full of pain and mysterious grasping in the dark.
I know actually functional languages like lisps do this better. I strongly suspect more declarative logic languages do better still. I also know from experience that the Excel interfaces most of our users interface are better than the XML experience, and I strongly suspect that’s closer to the pure/declarative + non-programming-accessible ideal than a markup language suited to other purposes.
> I wonder when XSLT will be re-invented and applied to JSON and YAML.
That's jq and its gojq friend (for its `--yaml-input`), right? If not a standard, damn near one as best I can tell. JMESPath (used by awscli and ansible) is a joke compared to the expressiveness of jq. There's also JSONPath in kubectl but it is similarly nowhere near as awesome as jq and not even complete in its attempt to be "XPath for JSON"
You can add types to JSON but it gets pretty funky, essentially sibling values. Pretty sure Google has some online details on how they try to keep JSON manageable internally.
> XML is Lisp’s bastard nephew, with uglier syntax and no semantics. Yet it is poised to enable the creation of a web of data that dwarfs anything since the Library at Alexandria.
From A Brief Defense of XML:
> ..Despite its roots in SGML (the Common Lisp of markup languages), the creators advertised it as a general format to exchange any digital information.
> All this effectively means that we can use XML for generic storage of source code. We'd be able to create a whole class of programming languages that use uniform syntax, as well as write transformers that convert existing source code to XML. If we were to actually adopt this idea, compilers for different languages wouldn't need to implement parsers for their specific grammars - they'd simply use an XML parser to turn XML directly into an abstract syntax tree.
> ..Everything we've learned about Lisp so far can be summarized by a single statement: Lisp is executable XML with a friendlier syntax.
Nearly everything I work on deals in XML, but end users who structure documents mostly don’t. I find the format confounding but less so than the more user facing alternatives. AMA I suppose? I’ll try to answer if you ask, but it might take me a while.
The completely unacceptable thing about XML 1.0 is that it can't express all of ASCII.
You might be thinking, "Duh, just escape it". Nope, ASCII control codes are forbidden you can't escape them, the escaped form is still forbidden. You can escape say, a backslash, or a quote mark, or an angle bracket, but you can't escape say a vertical tab.
So if you want to move arbitrary ASCII text (or Unicode text, since ASCII is a subset of Unicode) with XML you need to Base64 encode it, or you won't succeed.
15-20 years ago I wrote code which needed to square this particular circle where clients insisted that they want XML text and yet they also demand to handle the forbidden values, my code would just convert all impermissible values to Unicode's U+FFFD the Replacement Character.
> Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
I’m puzzled at the total non-mention of U+0000 in the document, which is a valid Unicode and ASCII character but is not supported by this definition of Char. So it seems like it’s actually (and using better terminology) “any Unicode scalar value, except U+0000, U+FFFE and U+FFFF”.
Control codes aren't text. Heck, HTML doesn't even support tabs -- whitespace is just generic whitespace, interpreted as a regular space.
If you want to insert non-typographic elements that affect the layout/presentation, that's what <elements> are for.
While if you need to encode binary data that can represent ASCII text, then yes -- Base64 is an ideal solution. That guarantees it won't be garbled by other XML processors.
The W3 basically says all this here [1]. ("Use of control codes in HTML and XHTML is never appropriate, since these markup languages are for representing text, not data.")
Sure it does. As does XML. You just have to choose deliberately to use it, via such means as <pre> or the CSS `white-space: pre`, or, in XML, the xml:space attribute.
Incidentally, HTML and the web is a place where the superiority of tab-based indentation to space-based is particularly apparent, because you’re far more likely to encounter very narrow viewports, where reducing the width of tabs is useful, while still keeping a reasonable indentation level on wide enough screens. I do something similar to this, for example:
Exactly. If you do want to encode control characters, the way to do that would be as character entities (which are simply text like &) and handle the translation of these entities at the application level. As an example, if we want a newline to be removed for presentation (or translated into a newline symbol like in Microsoft Word), the right place to do that would be at the rendering time and not in the data representation layer (which is where XML operates).
You could also use tags, for example <br> tag in HTML.
After all it is Extensible Markup Language and the functionality for adding custom tags is the basic feature.
And as suggested above, base64 encoding and application level decoding is also an accepted practice.
All these techniques point to handling the rendering at the application level.
> base64 encoding and application level decoding is also an accepted practice
I feel seen. I remember suggesting this during a design discussion where the issue was how to embed an arbitrary document in another, where the embedded document could even be ill-formed. Everybody told me it was a gross and dirty hack and ignored the suggestion.
It is quite a common pragmatic architectural pattern in the HTML architecture. For example, data urls where a MIME type representation is encoded in the URL format is used for embedding images and other MIME types.
So, if one is building an application and needs to render a proprietary data object, this is a good way (not the only one) to handle it using a client library.
The ~document chaos is real, but it's terminological chaos from before computing that turns into trouble when you're trying to mark it up.
Before computers, you could still reasonably use the term document to refer to things as different as an essay, poem, book manuscript, CV, patent, birth certificate, voter-registration form, and a court transcript.
It would be nice to cleave them apart, but that'll take a lot of work since our human languages have a dearth of good terms for discriminating between highly-structured and mostly-unstructured documents.
In those terms, the markup depicted in the linked piece's "document" is basically all "structural" markup--and I feel like this is the least interesting part of an unstructured document. It's the same logic that translates a paper address-change form into structured data describing what's in the fields--but it doesn't yield any of the leverage that we get from the meaningful associations in the form-as-markup.
We can't do much more with the structural markup of a free-form document than present it and perhaps translate it to other formats with similar idioms. Structure in this kind of document is somewhat capricious (if five different writers wrote exactly the same 20 pages of text, they might all still use different section/paragraph/sentence boundaries).
The bigger leverage in free-form documents comes from ontological markup that annotates what's being written about. This is what's going to enable you to bolt on an interesting extension that your readers can use to jump between every section on your site that discusses the same paper or author. Or enable you to automatically inject birth/death/release dates for people, films, and albums you refer to.
(I don't mean to suggest the post precludes these--but the verbosity comparison feels much less fair without enough inline annotation to provide a similar level of utility as the star record.)
XML isn't the problem. It would have been great if it had been introduced now, in a world totally comfortable with unstructured hash soups and trees and such.
Trying to map it cleanly to a strongly typed world was the problem.
Data exchange format? Yeah not great. I think it's got potential as a format for complicated text and markup heavy blobs though.
The idea of using XML as HTML was... an idea, but rather than trying to rationalize it as a super complicated dtd, they should have instead opened it up and defined mechanisms for creating custom tags, sort of like how React works now.
XML is great for applications where you might want to discard some or all of the data easily; shame the way it was employed required you to pretty explicitly handle every possible permutation of the data.
It is remarkable, when you think about it, how a language well designed for markup language somehow got transformed into a data exchange language.
It's easy to understand why -- pre-XML, data exchange formats were generally binary or otherwise non-readable. But once storage got generous enough that each byte stopped mattering, people looked for a textual data format that was easy to debug, and XML was available.
Still, it does make we wish a happy middle ground could have been found. An open standard something essentially like a compact binary format (similar to protobufs) but with a schema with field names and defined structure required at the top of every file. Which would require a dedicated app to view it, essentially similar to JSON once parsed. (While not transmitting the schema during communications but hard-coding it into the sender and receiver could serve as a poor man's obfuscation.)
I think a middle ground has been reached, XSLT 3.0 allows you to transform your XML into JSON and back. The XSLT 3.0 (2017) processor is available to non-Java languages from Saxonica, for Python "pip install saxonpy" (Linux only)
If you want to see how to do these XML-to-JSON and JSON-to-XML transforms I have written a little learning repo with a CLI: https://github.com/aleph2c/leaning_xslt
Folks are absolutely going to look at this from an inappropriate angle here (cuz... duh... we're nerds).
The side of the fence you're on is directly proportional to how old you are. Neckbeards who want you to get off their lawns love XML (related: get off my lawn). And the "kids" will give a bajillion reasons why we are "technically" incorrect...
If you split hairs here... You've never lived in a world without XML (truly terrifying TBH).
Neckbeards who want you to get off their lawns hate XML and will wax lyrical about how S-expressions endow data with type semantics, whereas XML just gives tree structure to pieces of text.
I don't think the things that makes programmers gag is plain old XML. As other comments noted, the markup/content ratio is a matter of your choice. And, as opposed to binary formats from the 80's and 90's, human readable (and debuggable). What I think makes programmers gag is the soul-killing universe of standards around XML and that there's always some architect or data person mandating their use. Things like SAML and XML signatures are a nightmare. Having to author a schema document or use a dozen namespaces every time you want to publish some data just makes it a drudge. XSLT was a bust. Average people didn't get it. You needed a rocket scientist to author the transforms. Let's not forget the joy of SOA and authoring WSDL documents. It wasn't XML, it was the uptight world of standards, best-practices, design by committee, and mandates that grew up around XML.
As someone who is trying to learn XSLT, I totally agree that it is really hard to learn! It's a functional programming language (lisp-like) that you write with verbose XML syntax. You operate over entire trees, your variables can't be changed and all of your functions are suppose to be written as tail recursions.
With this said, Michael Kay offers a nice series of patterns in chapter 17 of his book "XSLT 2.0 and XPath 2.0 Programmer's Reference". He shows how to use a "Fill-in-the-blanks" stylesheet that someone who only understands HTML can use, then he shows how to make a "Navigational Stylesheet", a "Rule-Based Stylesheet" and finally a "Computational Stylesheet". He shows that you don't necessarily need to use XSLT's functional programming powers, how you can get a lot with a little of it, and how to level up. So it seems like the language was designed to be written by people who don't understand it; it's declarative.
Once you understand those three patterns it does get a bit simpler. I wrote a ton of XSLT and XQuery years back and it's incredibly powerful when used well, plus I wrote a nifty little stylesheet that transformed any HTML page into a formatted and highlighted version of itself :)
Just wait. The same people are hard at working implementing them for JSON.
(There is already a JSON Schema definition at https://json-schema.org/)
Like you said - standard XML isn't terrible. Adding on an XSD isn't terrible, because now you can enforce structure and datatypes on files provided by outside parties. Creating an XSLT is much more of a mental challenge, and probably should be left to tools to define.
Anything beyond those technologies is someone polishing up their resume.
I used to write web applications in C++ which used XML and XSLT for almost everything. Our tag:content ratio was probably "very poor" (I don't believe we used attributes often at all).
Sounds the same as I worked on a few years later at a large medical publisher, both our applications and journals were all produced from the same underlying XML content.
The need to close tags has been a pretty low grumble about XML. It really doesn't matter. Especially with compression.
XML got a bad rap because SOAP & enterprise built nightmarish systems. It's possible to do very bad things with any kind of data interchange system, which, contrary to this post, I would say XML is & does fine at.
The irony is that all the "not particularly loved" technologies that have been built around xml are not really optional.
They solve concrete problems and if one wants to start fresh with something like JSON they need to be reinvented.
Once all the functionality is replicated its quite likely that the cognitive difficulty of mastering it all is - more or less - the same.
Lets also not forget that tech in all its forms has been quite democratized in the last decade. Corporate and academic environments do not always care about removing needless hoops and may even have incentives to keep things arcane and less accessible
98 comments
[ 3.8 ms ] story [ 160 ms ] threadThe tag-content ratio of XML is only as bad as you make it.
Admittedly, XML isn't the most pleasant syntax to interact with by hand.
The main idea, however, was wonderful. An information exchange format (xml itself), a way to define schemas (xsd), a transformation language (xslt), and stylesheets (xsl?). I kind of miss it.
XSLT and XPath each went on to great solo careers, XSL-FO kind of fizzled when XML+XSL failed to displace HTML+CSS.
There's also XQuery for transformations and XSD/RelaxNG for schemas, the whole combination of XML database, WYSIWYG (via XSLT) XML editor and output transformations is very powerful, every journal we published and every site we ran at the British Medical Journal was generated that way.
A lot of really stupid JavaScript could be done fairly easily with XSLT natively inside a browser engine. An XML document can point to its own XSL(s) so get rendered to the appropriate delivery format or just used directly as data.
No, I'm pretty sure that if they have only used XML syntax as a data rep and not XML-associated tooling like XSD, they are quite aware that when thet say they hate XML they are talking about syntax.
OTOH. I am surprised at the number of people that seem to thing “has a schema language that can be used to specify structure beyond just the basic raw language” distinguishes XML from other data representation languages.
Or, more generally, the way that “if you don’t like XML, maybe your problem is you aren’t using enough of it” has become an edgy contrarian position rather than steretypical establishment enterprise consultant thing it was 15 or so years ago.
JSON has .avro, I thought.
It's all data. Validation logic is sold separately.
JSON, like XML, has several schema languages, which have widely-available libraries for generating host language typings, validation, etc.
> Typing in XML is far richer than in JSON. There’s even a date type!
JSON Type Definition has timestamp, JSON Schema has date, date-time, time, and duration.
I've seen JSON schemas describe things like date types and plenty more. If you are including schema metadata alongside XML, then for a fair fight you can include JSON schemas, too.
A particularly unusual take is to ignore the difference and allow either attributes or child elements as different ways to do the same thing. This is what XAML does; e.g. this:
is identical to:If data should be presented to the user by a user agent that doesn't understand extensions to the markup, it should be using text nodes.
If it is a modification to a subset of a block of text, such as emphasizing a word, it should be a new element.
If it is a block of semantic metadata, you would structure that as a hierarchy of elements with attributes.
Otherwise, it is usually an attribute on an existing element.
SVG is a bit of a zany format in XML because so much of the content is points or encoded data, which get stuffed in some truly epic attributes.
XML wasn't really made for pure data formats, even though shoehorning that in was the majority of the market's effort.
Using plain tags is so obvious that just about anyone can get it, and in my experience there's no real advantage to using attributes.
At least that's my experience at work, where we use XML as our primary integration format for others that want to deliver data to our system. When going through with a new customer, the few attributes we have almost always cause some kind of issue or misunderstanding.
In the text markup role tags are like functions and the attributes are parameters to the functions. but in the data encoding role the attributes are another redundant key value store and you end up with a confusing mix where some of your kv's are in the tag and some are in the attributes and it is a bit of a mess.
There is a star tag(presumably a list of star tags) each of which contains a single position tag. The star tag is is full of attributes, and the position tag is full of attributes, now you have a complicated(not that complicated, hyperbola is for arguments sake) access method where you need to do different things based on what data you want out of the structure. Why was the position tag not an attribute? What happens when you want to encode the rightAscension, and declination, they will get their own tag, in fact they probably just should have tagged everything in the first place and avoided attributes.
So then:
We are, of course, playing into the article’s second footnote here.(Also: I’m curious why you turned the original document’s ″ (U+2033 DOUBLE PRIME) into " (", U+0022 QUOTATION MARK).)
I don't ever see double prime at my job, so it was probably muscle memory.
Compared to "string" and "character," not so much and not to so much misfortune.
Yaml specification makes Xml specification look like JSON.
If we are authoring content that we expect to last a few decades, markup is the proven engineering choice. It used to be sigil markup $1, $x, @@p etc., and other proprietary markup. SGML came and introduced DTDs, entities, parsing etc.,
DocBook format is pretty good for technical manuals. They pretty much covered 98% of the use cases for technical books. It would be foolish to invent a different format (using say JSON representation or some other proprietary format) for those use cases.
SGML grew too complex and then came XML in the late 90s and took off when SOAP started gaining traction for web services in the early '00s.
Unfortunately, XML almost went the SGML way on complexity with the addition of namespaces, multiple schema languages etc., But, we can never fault XML for its expressivity. There is also a good tooling available due to the work of many standardization workgroups and browser/vendor support.
If you choose to archive content using XML, you can be guaranteed that you can parse it 20-30 years later since XML is a simple format (if you use a simple subset of features).
But I don't think anyone is arguing that it's completely useless.
It just hasn't earned it's current privileged position in the computing world. It got there on the coattail of the obscene wave of hype around the turn of the century.
So it has a way to go as it slowly falls back to its rightful place.
I wonder when XSLT will be re-invented and applied to JSON and YAML. (XSLT was a bit of a miracle: a pure functional language adopted by a significant chunk of non-CS community in early 2000s. The syntax forced by XML sucked though. YAML can do better!)
(Could use S-expressions as well. The approach is 60+ years old now...)
Are you talking specifically about XSD and JSONSchema? If so I don't think this is really true. Pretty sure the original authors of JSONSchema didn't pay much attention to XSD.
So for a lot of XSD's I'd say JSON Schema is effectively very close.
Sadly, tooling for the latest JSON Schema (which is required for choice elements IIRC) is lacking, Swagger UI for example does not work well with it for example.
[1]: https://json-schema.org/draft/2020-12/json-schema-core.html
Can it do the reverse?
I don't see any big issues with doing it in reverse for a subset of JSON Schema.
What I haven't looked at is how large that subset would be. That is, if JSON Schema contains things that aren't possible to represent in XSD.
For example, JSON Schema allows for some extensive conditional sub-schema logic. I used the "oneOf" to represent a XSD choice element, however JSON Schema also allows for such things as "if..then..else", which as a self-taught non-expert on XSD's I'm not sure how would map to XSD on a Saturday morning.
Of course, there are things in XSD which can't be represented in JSON Schema either, I'm sure it's easy to come up with something that doesn't map. But from the typical XSD's I've seen and the ones we had in our company, the mapping could be done with just a single special-case.
Given the lack of tooling around JSON Schema, my workflow now is to create/update the XSD and regenerate the JSON Schema.
I really don’t think YAML and its own terse but ambiguous rules are better suited. The problem I’ve found in XSLT during this effort, and in YAML in the past, is there’s no debugging story that isn’t full of pain and mysterious grasping in the dark.
I know actually functional languages like lisps do this better. I strongly suspect more declarative logic languages do better still. I also know from experience that the Excel interfaces most of our users interface are better than the XML experience, and I strongly suspect that’s closer to the pure/declarative + non-programming-accessible ideal than a markup language suited to other purposes.
That's jq and its gojq friend (for its `--yaml-input`), right? If not a standard, damn near one as best I can tell. JMESPath (used by awscli and ansible) is a joke compared to the expressiveness of jq. There's also JSONPath in kubectl but it is similarly nowhere near as awesome as jq and not even complete in its attempt to be "XPath for JSON"
http://move.rupy.se/file/logic.html
> XML is Lisp’s bastard nephew, with uglier syntax and no semantics. Yet it is poised to enable the creation of a web of data that dwarfs anything since the Library at Alexandria.
From A Brief Defense of XML:
> ..Despite its roots in SGML (the Common Lisp of markup languages), the creators advertised it as a general format to exchange any digital information.
From The Nature of Lisp: https://www.defmacro.org/ramblings/lisp.html
> All this effectively means that we can use XML for generic storage of source code. We'd be able to create a whole class of programming languages that use uniform syntax, as well as write transformers that convert existing source code to XML. If we were to actually adopt this idea, compilers for different languages wouldn't need to implement parsers for their specific grammars - they'd simply use an XML parser to turn XML directly into an abstract syntax tree.
> ..Everything we've learned about Lisp so far can be summarized by a single statement: Lisp is executable XML with a friendlier syntax.
It was still kind of verbose, but effective.
Eventually switched to Markdown+Pandoc+more custom scripts. Formatting Objects and Apache FOP seemed to be on the back burner anyway.
I like XML for markup in theory, and the formality is nice, but, damn, is Markdown nicer in practice for documents.
You might be thinking, "Duh, just escape it". Nope, ASCII control codes are forbidden you can't escape them, the escaped form is still forbidden. You can escape say, a backslash, or a quote mark, or an angle bracket, but you can't escape say a vertical tab.
So if you want to move arbitrary ASCII text (or Unicode text, since ASCII is a subset of Unicode) with XML you need to Base64 encode it, or you won't succeed.
15-20 years ago I wrote code which needed to square this particular circle where clients insisted that they want XML text and yet they also demand to handle the forbidden values, my code would just convert all impermissible values to Unicode's U+FFFD the Replacement Character.
> Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
I’m puzzled at the total non-mention of U+0000 in the document, which is a valid Unicode and ASCII character but is not supported by this definition of Char. So it seems like it’s actually (and using better terminology) “any Unicode scalar value, except U+0000, U+FFFE and U+FFFF”.
The same restriction you noted on entity encoding still holds: https://www.w3.org/TR/xml11/#NT-CharRef
Control codes aren't text. Heck, HTML doesn't even support tabs -- whitespace is just generic whitespace, interpreted as a regular space.
If you want to insert non-typographic elements that affect the layout/presentation, that's what <elements> are for.
While if you need to encode binary data that can represent ASCII text, then yes -- Base64 is an ideal solution. That guarantees it won't be garbled by other XML processors.
The W3 basically says all this here [1]. ("Use of control codes in HTML and XHTML is never appropriate, since these markup languages are for representing text, not data.")
[1] https://www.w3.org/International/questions/qa-controls
Sure it does. As does XML. You just have to choose deliberately to use it, via such means as <pre> or the CSS `white-space: pre`, or, in XML, the xml:space attribute.
Incidentally, HTML and the web is a place where the superiority of tab-based indentation to space-based is particularly apparent, because you’re far more likely to encounter very narrow viewports, where reducing the width of tabs is useful, while still keeping a reasonable indentation level on wide enough screens. I do something similar to this, for example:
You could also use tags, for example <br> tag in HTML.
After all it is Extensible Markup Language and the functionality for adding custom tags is the basic feature.
And as suggested above, base64 encoding and application level decoding is also an accepted practice.
All these techniques point to handling the rendering at the application level.
I feel seen. I remember suggesting this during a design discussion where the issue was how to embed an arbitrary document in another, where the embedded document could even be ill-formed. Everybody told me it was a gross and dirty hack and ignored the suggestion.
So, if one is building an application and needs to render a proprietary data object, this is a good way (not the only one) to handle it using a client library.
Is XML meant to represent only text and not data?
Before computers, you could still reasonably use the term document to refer to things as different as an essay, poem, book manuscript, CV, patent, birth certificate, voter-registration form, and a court transcript.
It would be nice to cleave them apart, but that'll take a lot of work since our human languages have a dearth of good terms for discriminating between highly-structured and mostly-unstructured documents.
I struggled through writing something roughly about this last year: https://t-ravis.com/post/doc/what_color_is_your_markup/
In those terms, the markup depicted in the linked piece's "document" is basically all "structural" markup--and I feel like this is the least interesting part of an unstructured document. It's the same logic that translates a paper address-change form into structured data describing what's in the fields--but it doesn't yield any of the leverage that we get from the meaningful associations in the form-as-markup.
We can't do much more with the structural markup of a free-form document than present it and perhaps translate it to other formats with similar idioms. Structure in this kind of document is somewhat capricious (if five different writers wrote exactly the same 20 pages of text, they might all still use different section/paragraph/sentence boundaries).
The bigger leverage in free-form documents comes from ontological markup that annotates what's being written about. This is what's going to enable you to bolt on an interesting extension that your readers can use to jump between every section on your site that discusses the same paper or author. Or enable you to automatically inject birth/death/release dates for people, films, and albums you refer to.
(I don't mean to suggest the post precludes these--but the verbosity comparison feels much less fair without enough inline annotation to provide a similar level of utility as the star record.)
Trying to map it cleanly to a strongly typed world was the problem.
The idea of using XML as HTML was... an idea, but rather than trying to rationalize it as a super complicated dtd, they should have instead opened it up and defined mechanisms for creating custom tags, sort of like how React works now.
XML is great for applications where you might want to discard some or all of the data easily; shame the way it was employed required you to pretty explicitly handle every possible permutation of the data.
It's easy to understand why -- pre-XML, data exchange formats were generally binary or otherwise non-readable. But once storage got generous enough that each byte stopped mattering, people looked for a textual data format that was easy to debug, and XML was available.
Still, it does make we wish a happy middle ground could have been found. An open standard something essentially like a compact binary format (similar to protobufs) but with a schema with field names and defined structure required at the top of every file. Which would require a dedicated app to view it, essentially similar to JSON once parsed. (While not transmitting the schema during communications but hard-coding it into the sender and receiver could serve as a poor man's obfuscation.)
If you want to see how to do these XML-to-JSON and JSON-to-XML transforms I have written a little learning repo with a CLI: https://github.com/aleph2c/leaning_xslt
Here is Michael Kay's white paper on Transforming JSON using XSLT 3.0: https://www.saxonica.com/papers/xmlprague-2016mhk.pdf
Once your data is in a JSON format, you could implement your compact-binary-format idea around it.
The side of the fence you're on is directly proportional to how old you are. Neckbeards who want you to get off their lawns love XML (related: get off my lawn). And the "kids" will give a bajillion reasons why we are "technically" incorrect...
If you split hairs here... You've never lived in a world without XML (truly terrifying TBH).
Neckbeards who want you to get off their lawns hate XML and will wax lyrical about how S-expressions endow data with type semantics, whereas XML just gives tree structure to pieces of text.
With this said, Michael Kay offers a nice series of patterns in chapter 17 of his book "XSLT 2.0 and XPath 2.0 Programmer's Reference". He shows how to use a "Fill-in-the-blanks" stylesheet that someone who only understands HTML can use, then he shows how to make a "Navigational Stylesheet", a "Rule-Based Stylesheet" and finally a "Computational Stylesheet". He shows that you don't necessarily need to use XSLT's functional programming powers, how you can get a lot with a little of it, and how to level up. So it seems like the language was designed to be written by people who don't understand it; it's declarative.
Like you said - standard XML isn't terrible. Adding on an XSD isn't terrible, because now you can enforce structure and datatypes on files provided by outside parties. Creating an XSLT is much more of a mental challenge, and probably should be left to tools to define.
Anything beyond those technologies is someone polishing up their resume.
yaml, json, xml all seem to be disliked.
ini works, but is pretty limited. It's also likely disliked, but just (at this point) obscure.
Don't really have anything bad to say about it.
"Web framework"? Hahaha!
UI (HTML/etc) was produced by XSLT at request time; such JS as we used was our own; Apache/FastCGI; uhhhh.
XML got a bad rap because SOAP & enterprise built nightmarish systems. It's possible to do very bad things with any kind of data interchange system, which, contrary to this post, I would say XML is & does fine at.
They solve concrete problems and if one wants to start fresh with something like JSON they need to be reinvented.
Once all the functionality is replicated its quite likely that the cognitive difficulty of mastering it all is - more or less - the same.
Lets also not forget that tech in all its forms has been quite democratized in the last decade. Corporate and academic environments do not always care about removing needless hoops and may even have incentives to keep things arcane and less accessible