Great video and to the point! When I started using XML for "real world" data back in the 1990s I really found my self in a straight jacket. A "huge" problem was double hiearchies, which often occurs in the real world and seldom in documents. Then it occured to me that XML was really the same data model as the IBM IMS from the mid 1960s. In my early dbms design and development I used the Codasyl network model which included that a node could be part of two different hiearchies, i.e. had a parent and a step-parent,direct link from grandchild to grandparent and so on. So I though of XML as pre Codasyl (Network model), i.e. modeling pre 1970s. When JSON came about it was also a flash back, since it in a way like re-inventing th Relational Datamodel (Codd 1974). And I finally could use objects, lists and arrays like in a relational DBMS and with less "rules"
Sounds like the lesson we all learn sooner or later. Hard problems in communications or semantics never get magically removed by specific technologies. All those can do is to give us a hopefully better starting point to manage them.
This is where all technical discussions should begin, the “Why?”. What problem compelled the choices or the reality we live in…I don’t understand why in the modern world we care so little about the “Why?”. I believe it is why we end up feeling trapped learning and using the wrong tools, the problem the tools were built to solve has long been solved and now we have new problems but the tool we are using became dogma.
I couldn't agree more! I always wondered why some formats were used when others were, in my opinion, so much better - like certainly they had reasons, but how am I to see the value of a format if i dont know those reasons? How am I to even actually know what is good? Or to learn to develop new good stuff? That is also probably why there is so much reinventing the wheel going on - people just forget about stuff because those inbetween didnt see reasons to keep them.
Thanks for this video. I’m currently working on a project that needs some data, basically lists of protocols for radiation therapy plans. I wanted to avoid adding a database initially, so I created the protocols in a plain text document using xml. But over the last week I’ve been thinking json would probably have been better. Your video pushed my 100% there. Will be converting xml to json. May even bite the bullet and create the database.
While there are XML databases they are not super popular. So if your structured data should be available in a database to store and query at scale, choosing JSON probably is a better idea.
For sure DOM hurt XML, and for sure JSON is a better fit when the programmer is in total control of the format. It's not 100% true that we didn't think about such infrastructure use cases when developing XML, but you're right that documents were primary.
thanks for the comment, liam. i am sure you remember that i always was a big fan of XML, and i still am. but here it's all about the famous maslow quote, and XML turned out not to be such a great hammer for most API nails.
Seems to me a huge weakness of XML is that you need a schema to parse the basics like: is this node an array? Is this value a string, bool or number? In JSON at least you know that much.
It's true that XML doesn't have the kind of "data-oriented" typing that JSON has (even though it's extremely minimal in JSON). But that's because XML wasn't intended to be a data format. There's a minimal type model for attributes, but that again never was intended for data typing.
@@ErikWilde True. I guess that's why it lost as a data format. Intended for something else than how most web apps use data. (as you did mention in the video 👍)
What about complex json structures? Are you not thinking of mini api's versus bigger api's? The complexity is moving away/out of the one data structure but reappearing in the orchestration of the many api's... no?
there is complexity (the "natural complexity" of a domain) and complication (the "artificial complexity" added by picking a particular solution/technology. you cannot make complexity go away, but i think that the "XML complication" is something that most developers saw being removed for them in JSON-based approaches. many other things play into this. for example the emergence of GraphQL, which moved complexity from multiple API interactions to a more manageable complexity in a single API with a schema and query language. shifting complexity around always is very much a design exercise. but XML (for most applications and users) simply was a complication: the trees, the element/attribute duality, namespaces, data binding and serialization: none of that came from the domain, it was just XML complication.
@@ErikWilde lets put in simple words : How we will represent the JSON for the structure that you have shown in you video where we have paragraph with some embedded text, anchors, references etc. kind of mixed data model to use conveniently with other object?
@@vishnusingh2245 to be honest, i don't think that there's a reasonable way to represent that example in JSON. that's where XML is more flexible with allowing mixed content (characters mixed with elements) and much more variety in its structures. i am sure you can come up with *some* JSON representing the XML document snippet, but using it would be almost certainly excruciatingly painful to use for anything.
Great post ! I completely agree and buy your hypothesis. There is one thong though that doesn't fit and this is that most Document oriented databases (like MongoDB or CouchDB) use JSOn and not XML to store structured documents. Could it be that these engines are used within JabaScript code ?
To be honest, i don't consider MongoDB or CouchDB to be document databases. They are NoSQL for sure, but if you're serious about structured documents, it's unlikely that you would choose JSON as your foundation. It seems that the term "document database" has a rather fuzzy meaning nowadays, and mostly refers to the fact that you can store "entire objects/documents" (as opposed to SQL and its fine-grained row structure). In my mind, when people talk about "document databases", it rarely is specifically about storing actual documents (in the sense of semi-structured and mixed content).
I too catched up with XML, SOAP is still a thing, what most disliked that XSD /XSLT, Xpath , it just to verbose. In SOAP you need to maintain the WSDL on client and server side, and of course it did many times wrong.
Before XML you had standards like the horrible EDIFACT for machine to machine communications, compared to them XML is a bless and JSON is even better. en.wikipedia.org/wiki/EDIFACT
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
I cannot overstate how much I appreciate a video on the WHY of computer programming formats and concepts and not just another generic HOW video.
Thank you for the explanation of XML in its original context. Have a great day!
Great video and to the point! When I started using XML for "real world" data back in the 1990s I really found my self in a straight jacket. A "huge" problem was double hiearchies, which often occurs in the real world and seldom in documents. Then it occured to me that XML was really the same data model as the IBM IMS from the mid 1960s. In my early dbms design and development I used the Codasyl network model which included that a node could be part of two different hiearchies, i.e. had a parent and a step-parent,direct link from grandchild to grandparent and so on. So I though of XML as pre Codasyl (Network model), i.e. modeling pre 1970s. When JSON came about it was also a flash back, since it in a way like re-inventing th Relational Datamodel (Codd 1974). And I finally could use objects, lists and arrays like in a relational DBMS and with less "rules"
Sounds like the lesson we all learn sooner or later. Hard problems in communications or semantics never get magically removed by specific technologies. All those can do is to give us a hopefully better starting point to manage them.
I like the way you structured the content in the video. Simple and interesting!
Thanks a lot, @Roger!
This is where all technical discussions should begin, the “Why?”.
What problem compelled the choices or the reality we live in…I don’t understand why in the modern world we care so little about the “Why?”. I believe it is why we end up feeling trapped learning and using the wrong tools, the problem the tools were built to solve has long been solved and now we have new problems but the tool we are using became dogma.
I couldn't agree more!
I always wondered why some formats were used when others were, in my opinion, so much better - like certainly they had reasons, but how am I to see the value of a format if i dont know those reasons?
How am I to even actually know what is good? Or to learn to develop new good stuff?
That is also probably why there is so much reinventing the wheel going on - people just forget about stuff because those inbetween didnt see reasons to keep them.
Really appreciate the history of the 2 formats. Great content. Thank you
Very appreciative! Good info!
Thanks for this video. I’m currently working on a project that needs some data, basically lists of protocols for radiation therapy plans. I wanted to avoid adding a database initially, so I created the protocols in a plain text document using xml. But over the last week I’ve been thinking json would probably have been better. Your video pushed my 100% there. Will be converting xml to json. May even bite the bullet and create the database.
While there are XML databases they are not super popular. So if your structured data should be available in a database to store and query at scale, choosing JSON probably is a better idea.
Nicely explained, thank you
What I dislike about both of them is that both are in effect trees. I want the power of a graph.
Then you should check out RDF. You'll love it!
Great video, thank you for your time
Nice video. Thanks for posting
Great explanation! Thanks!
Graet explaination
thanks ❤
For sure DOM hurt XML, and for sure JSON is a better fit when the programmer is in total control of the format. It's not 100% true that we didn't think about such infrastructure use cases when developing XML, but you're right that documents were primary.
thanks for the comment, liam. i am sure you remember that i always was a big fan of XML, and i still am. but here it's all about the famous maslow quote, and XML turned out not to be such a great hammer for most API nails.
Why is Antonio Banderas giving a lecture on JSON 😳
Thanks.?.very easy to understand.
Interesting. 😃👍
As someone who wants to transition from UX to technical writing, which would be most appropriate to learn? For API documentation
Seems to me a huge weakness of XML is that you need a schema to parse the basics like: is this node an array? Is this value a string, bool or number?
In JSON at least you know that much.
It's true that XML doesn't have the kind of "data-oriented" typing that JSON has (even though it's extremely minimal in JSON). But that's because XML wasn't intended to be a data format. There's a minimal type model for attributes, but that again never was intended for data typing.
@@ErikWilde True. I guess that's why it lost as a data format. Intended for something else than how most web apps use data. (as you did mention in the video 👍)
What about complex json structures? Are you not thinking of mini api's versus bigger api's? The complexity is moving away/out of the one data structure but reappearing in the orchestration of the many api's... no?
there is complexity (the "natural complexity" of a domain) and complication (the "artificial complexity" added by picking a particular solution/technology. you cannot make complexity go away, but i think that the "XML complication" is something that most developers saw being removed for them in JSON-based approaches.
many other things play into this. for example the emergence of GraphQL, which moved complexity from multiple API interactions to a more manageable complexity in a single API with a schema and query language. shifting complexity around always is very much a design exercise.
but XML (for most applications and users) simply was a complication: the trees, the element/attribute duality, namespaces, data binding and serialization: none of that came from the domain, it was just XML complication.
@@ErikWilde lets put in simple words : How we will represent the JSON for the structure that you have shown in you video where we have paragraph with some embedded text, anchors, references etc. kind of mixed data model to use conveniently with other object?
@@vishnusingh2245 to be honest, i don't think that there's a reasonable way to represent that example in JSON. that's where XML is more flexible with allowing mixed content (characters mixed with elements) and much more variety in its structures. i am sure you can come up with *some* JSON representing the XML document snippet, but using it would be almost certainly excruciatingly painful to use for anything.
@@vishnusingh2245 what a stupid question!!!
@@aledesc I don't think asking questions is a stupid thing in TechWorld. We just need to learn and explore!
API for whom? For many backend developers we live by XML and it's technologies. It's other things for frontend developers
Great post ! I completely agree and buy your hypothesis. There is one thong though that doesn't fit and this is that most Document oriented databases (like MongoDB or CouchDB) use JSOn and not XML to store structured documents. Could it be that these engines are used within JabaScript code ?
To be honest, i don't consider MongoDB or CouchDB to be document databases. They are NoSQL for sure, but if you're serious about structured documents, it's unlikely that you would choose JSON as your foundation. It seems that the term "document database" has a rather fuzzy meaning nowadays, and mostly refers to the fact that you can store "entire objects/documents" (as opposed to SQL and its fine-grained row structure). In my mind, when people talk about "document databases", it rarely is specifically about storing actual documents (in the sense of semi-structured and mixed content).
I too catched up with XML, SOAP is still a thing, what most disliked that XSD /XSLT, Xpath , it just to verbose. In SOAP you need to maintain the WSDL on client and server side, and of course it did many times wrong.
02:30 1998
Content is great...audio sucks
Before XML you had standards like the horrible EDIFACT for machine to machine communications, compared to them XML is a bless and JSON is even better.
en.wikipedia.org/wiki/EDIFACT