tag:blogger.com,1999:blog-3944976411672994427.post7046188846926386851..comments2023-09-03T17:53:38.313+07:00Comments on James Clark's Random Thoughts: XML vs the WebJames Clarkhttp://www.blogger.com/profile/04798042939786677843noreply@blogger.comBlogger42125tag:blogger.com,1999:blog-3944976411672994427.post-31161071566589022682012-06-25T20:26:47.343+07:002012-06-25T20:26:47.343+07:00Hi James,
"In the short-term, I think the ch...Hi James,<br /><br />"In the short-term, I think the challenge is how to make HTML5 play more nicely with XML."<br /><br />By reference, clearly. On the Web, that means links, link annotations, etc.: <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="nofollow">http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven</a>.Peter Rushforthhttps://www.blogger.com/profile/09472639836847800891noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-45121689612849374652011-06-27T23:17:07.745+07:002011-06-27T23:17:07.745+07:00While JSON may be gaining traction, I believe that...While JSON may be gaining traction, I believe that XML and JSON serve different purposes by design. JSON is a data structure containment based system. XML is an extension based data representation scheme. In large part I agree that JSON is not well suited for some tasks, however, when it comes to programming : JSON contains simple rules compared to the complexities of tag attributes and mixed content. XML uses these attributes but does not enforce them nor give good reason to use them compared to wrapping things in tags from the many times I have used them. Consistently checking if I am in a mixed content node (lord knows if someone inserts a tag where there shouldn't be one) or an attribute node exists (did it get defaulted by a namespace?) instead of a consistent means of accessing data being used as such is confusing when deadlines are important. Schemas are amazing, and I wish it were easier to have them supported, but largely vendors will not give correct formed XML at all times, with JSON the risk is largely reduced due to lower complexity. Having mixed content and attributes is a strength for development of content in XML, but I largely feel that this added complexity to the programming side is hard to deal with compared to the simple set/map/value structures that are presented in JSON.diseño webhttp://www.ki-design.com.ar/noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-69714242180501610892011-03-16T06:58:53.739+07:002011-03-16T06:58:53.739+07:00"In particular, JSON shines as a programming ..."In particular, JSON shines as a programming language-independent representation of typical programming language data structures."<br /><br />What about references? Isn't this a typical programming language data structure that is missing in JSON?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-59995805080196723232011-03-11T05:18:56.364+07:002011-03-11T05:18:56.364+07:00I've taken a look at the current JSON schema p...I've taken a look at the current JSON schema proposals, and it appears to me that they miss the mark. Specifically, it appears to me that they don't allow context-free-grammar specifications as Relax NG does. Perhaps I'm being na\"ive, but it appears to me that there's a golden opportunity to just strip down the Relax NG syntax to match JSON: get rid of element tags and attributes, formulate a simple syntax for name->value mappings.<br /><br />The result would appear to be a usable and efficient schema language for JSON.<br /><br />No?John Clementshttps://www.blogger.com/profile/15701081040575095781noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-47391562418236328852010-12-11T15:37:27.492+07:002010-12-11T15:37:27.492+07:00EPUB2 uses XHTML 1.1. EPUB3 will use XHTML5 and w...EPUB2 uses XHTML 1.1. EPUB3 will use XHTML5 and will not allow non-XML HTML5. BTW, EPUB uses RELAX NG and NVDL.村田https://www.blogger.com/profile/16552967103277070244noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-35785060067154385672010-12-08T22:07:14.198+07:002010-12-08T22:07:14.198+07:00Speaking as one of many on the Web Development com...Speaking as one of many on the Web Development community: with SVG getting support in all major browsers (including IE9), I expect my interest in XML to go back up, but that's about it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-11471820512145170992010-12-08T04:16:35.214+07:002010-12-08T04:16:35.214+07:00Just thought I'd chime in with a thought on th...Just thought I'd chime in with a thought on this oft debated subject as I've been developing with XML for the better part of the last 10 years and have also dabbled a bit with JSON over the last 3 years or so.<br /><br />The attraction to JSON for most web developers is that it was designed with no-frills JavaScript serialization right from the start. It is the right tool for the job because it was designed for a very specific purpose.<br /><br />XML on the other hand was supposed to be a simplified yet compatible subset of SGML, that vastly complex world of descriptive markup. XML was to solve the complexities of SGML while preserving the benefits. It is flexible enough to describe data between client and server, but that's just one of its capabilities not its specialization.<br /><br />The way I see it XML and JSON don't necessarily compete with each other, they are equally adept at what they do. Their scope is what is different.<br /><br />My hope is that JSON doesn't become as arcane and frustrating as XML seems to be for many newcomers, time will tell on that one though.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-53604309460231222202010-12-06T21:57:41.474+07:002010-12-06T21:57:41.474+07:00While JSON may be gaining traction, I believe that...While JSON may be gaining traction, I believe that XML and JSON serve different purposes by design. JSON is a data structure containment based system. XML is an extension based data representation scheme. In large part I agree that JSON is not well suited for some tasks, however, when it comes to programming : JSON contains simple rules compared to the complexities of tag attributes and mixed content. XML uses these attributes but does not enforce them nor give good reason to use them compared to wrapping things in tags from the many times I have used them. Consistently checking if I am in a mixed content node (lord knows if someone inserts a tag where there shouldn't be one) or an attribute node exists (did it get defaulted by a namespace?) instead of a consistent means of accessing data being used as such is confusing when deadlines are important. Schemas are amazing, and I wish it were easier to have them supported, but largely vendors will not give correct formed XML at all times, with JSON the risk is largely reduced due to lower complexity. Having mixed content and attributes is a strength for development of content in XML, but I largely feel that this added complexity to the programming side is hard to deal with compared to the simple set/map/value structures that are presented in JSON.Bradleyhttps://www.blogger.com/profile/03062713177364563086noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-88979835820813823892010-12-06T05:04:11.069+07:002010-12-06T05:04:11.069+07:00You can discuss is issues like XML vs. JSON on tho...You can discuss is issues like XML vs. JSON on thousands of pages and it stills boils down to the epic decision: safe validated types, or duck typing, which you're also solving when picking programming language. JSON is just better choices for Javascript/Python/Ruby programmer, XML does better job with Java and C++.skrathttps://www.blogger.com/profile/15487467627010327242noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-88315943203977944622010-12-04T00:48:49.766+07:002010-12-04T00:48:49.766+07:00There is something of a natural cycle here. As a t...There is something of a natural cycle here. As a technology (let's call it that for simplicity) like XML becomes widely used over time, more and more standards appear to extend and refine it. More and more tooling appears to extend it's use into additional scenarios. The result is the complexity you lament in the case of XML.<br /><br />Eventually another technology comes along (witness JSON in this case) to reduce the clutter and focus on some specific scenarios of key concern. <br /><br />JSON will certainly follow this same path, until another technology appears to reduce the complexity that by that time will surrounds JSON. It's a natural evolution, and the key as developers is to evolve with it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-69164990979198043122010-12-01T15:50:30.767+07:002010-12-01T15:50:30.767+07:00There is no difficulty to develop a support of XML...There is no difficulty to develop a support of XML inside browsers which could give JSON-like access : root.tag1.@attr<br />That is done in script languages like Python or Scala.<br />The problem of XML in the code is that accessing nodes from compiled languages is hard :<br />- DOM is incredibly poor (getElementsByTagName is simply useless)<br />- XPath is good but not performant (an evaluation is several miliseconds long).<br />- deserialization into POJOs is a nightmare, you just spend your developer's life to modify getters and setters<br />I have seen a very good improvement with ElementTraversal specification. but it misses a performant method getChild(String childName), accessing a HashMap of the children.<br />All that is only coming from HTML which does not self-close its tags ?? That is sad.Unknownhttps://www.blogger.com/profile/12861495814824724930noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-68632256696065024192010-12-01T09:54:22.604+07:002010-12-01T09:54:22.604+07:00hi guys. dumb question: it seems that there's ...hi guys. dumb question: it seems that there's a nice plus to using XHTML if your data has a link structure. while debugging your app, you can navigate around your data by simply pointing your browser to the root. (analogy: file: pages.). the served XHTML is both human and computer consumable. <br /><br />but if we ditch XML, I think we lose this dual consumable property. james, is this what you were referring to by mixed content? would appreciate some illumination. thx.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-76433584846051307052010-12-01T08:30:54.776+07:002010-12-01T08:30:54.776+07:00Json is so compact and convenient, but I still fin...Json is so compact and convenient, but I still find myself sending arrays as they can be equally compact and much easier to traverse client side.jameshttp://www.sitebyjames.com/noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-68983568884833713262010-12-01T07:50:19.032+07:002010-12-01T07:50:19.032+07:00FWIW, I got around the <a id="a"/>...FWIW, I got around the <a id="a"/> problem by coding my XSL to output <a id="a"><!-- a --></a>.<br /><br />Sticking that comment in there kept the XML tool from closing it up to an empty element.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-72529400505902790402010-12-01T06:20:17.929+07:002010-12-01T06:20:17.929+07:00Hi James,
I certainly think that it's possibl...Hi James,<br /><br />I certainly think that it's possible for XML and JSON to co-exist. We've taken advantage of both at <a href="http://www.skechers.com/" rel="nofollow">skechers.com</a> (check the source and the Net tab of Firebug). XML still seems like a viable technology, and I don't think anyone is necessarily moving away from it.Mark Beesonhttp://www.skechers.com/noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-20448204603398624842010-12-01T06:01:56.001+07:002010-12-01T06:01:56.001+07:00XML had my support and enthusiasm. I honestly have...XML had my support and enthusiasm. I honestly have it a chance, even served my XSTL-generated website as application/xhtml+xml.<br /><br />but…<br /><br />DTD is idiocy. <br /><br />I facepalmed when I discovered that to write XML parser (it's strict, so it's easy to parse, right? hello?), one has to write SGML parser first, and not make it susceptible to million laughs attack.<br /><br />And draconian handling started to bite me left and right. I had my web site broken by mobile operator's proxies (sure, wouldn't happen in alternate universe where everyone used XML). <br /><br />I had my site broken by my own tools (my bad. But my users saw the error, and I didn't!)<br /><br />I had to parse data feeds from 3rd party that couldn't wrap head around whole escaping concept. Totally their fault, and they should fix it, says XML. But my boss, my deadlines said otherwise.kkll2https://www.blogger.com/profile/02340731619715153384noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-84142887091811328912010-12-01T05:23:26.620+07:002010-12-01T05:23:26.620+07:00I believe E4X tried to bridge that gap and hasn...<i>I believe E4X tried to bridge that gap and hasn't received enough traction from the web dev community.</i><br /><br />E4X is fantastic. Unfortunately, it's only supported in Firefox (and other browsers using the same JS engine), and even there you need to use a special "e4x=1" flag around your scripts (but only sometimes?).<br /><br />So I would agree with you, if by "web dev community" you mean "people who *write* web browsers". Those of us who write *for* web browsers love E4X, and would use it 1000 times a day, if only it was supported.<br /><br />It seems all the browser projects got sidetracked for a couple years in the JS Speed Race, where the only thing that matters is how big the bargraph next to your name is in some arbitrary JS benchmark. Which is great for some things, and I can't fault them for it, but it was kind of lousy for making feature progress on JS-the-language.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-26254988695987756992010-12-01T02:48:58.342+07:002010-12-01T02:48:58.342+07:00As a web dev, my reaction to seeing anything in XM...As a web dev, my reaction to seeing anything in XML is usually dismay. I just know that I'm going to have to deal with something horribly overcomplicated, overdesigned, verbose and intractable. Even the most trivial XML config file (e.g. OS X plists) is utterly unsuited to human consumption and usually require a ridiculously overweight software stack to process properly. SOAP interfaces are a classic example: I've never seen one that I'd class as usable or performant - salesforce.com is just a joke - or that could be used without thousands of lines of library code.<br />Overall, XML: great idea, awful reality.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-46671969624959519292010-12-01T02:22:02.616+07:002010-12-01T02:22:02.616+07:00When I look at JSON vs XML. I think of the two as ...When I look at JSON vs XML. I think of the two as having the same difference as dynamic vs statically typed languages. JSON is gaining traction largely because dynamic languages are gaining traction. When you need something with better guarantees then you go to XML.Blacktigerhttps://www.blogger.com/profile/02629290772651452425noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-64071148106888638302010-11-29T22:09:40.013+07:002010-11-29T22:09:40.013+07:00As a developer who has used both technologies from...As a developer who has used both technologies from their inception...<br /><br />XML has become too complicated. While DTD, XSLT, XPath, XQuery, etc all had good intentions, they have complicated XML until it is no longer practical to use, except for application configuration and passing data between computers ON THE BACKEND.<br /><br />JSON has the advantage on the frontend of tight integration with Javascript (requiring no additional controls or parsing) and compact data. The same data in JSON is easily half the size of using XML.<br /><br />And the catalyst for all this is not browsers or app design, but phone web applications! HTML5/CSS3 have been advanced by the browsers that come with iPhone and Android. On the mobile platform, data transmission is expensive... and is why JSON (which has been around for a few years) is now exploding.<br /><br />As a developer, I will use XML for app config and backend data passing, but JSON now rules for passing data to a (mobile) browser client.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-54999550165179201202010-11-28T10:44:32.399+07:002010-11-28T10:44:32.399+07:00@shoebappa: Look a little more closely. Yes, you c...@shoebappa: Look a little more closely. Yes, you can associate a CSS stylesheet with XML, but there a host of HTML behaviours that remain embedded in HTML. And really, they should have been torn out and put in CSS a long time ago.<br /><br />An ideal world, in my view:<br /><br />A browser reads a document. If it sees an HTML-style tag, it defaults to the base HTML behaviour. It then overlays the stylesheet, and applies behaviour based on the stylesheet.<br /><br />This would allow both for display of pure XML in browsers with all the capabilities of HTML; it would allow for straight HTML; and it allow for mixed content, where someone wants to introduce an XML document fragment into an otherwise HTML document.<br /><br />I still can't make a link via CSS. This is a rather silly situation.Ben Traffordhttps://www.blogger.com/profile/10822392620101203055noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-12414061536797632652010-11-27T23:51:06.532+07:002010-11-27T23:51:06.532+07:00This thread has also been picked up on the xml-dev...This thread has also been picked up on the xml-dev list, and is spawning some interesting commentary there.Anonymoushttps://www.blogger.com/profile/11746604103523406806noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-43894620968754138442010-11-27T14:01:35.551+07:002010-11-27T14:01:35.551+07:00@Ben Trafford, I can't disagree with most of w...@Ben Trafford, I can't disagree with most of what you said, but the CSS + XML statement appears pretty off base: <a href="http://www.w3.org/Style/styling-XML.html" rel="nofollow">http://www.w3.org/Style/styling-XML.html</a><br /><br />I haven't followed the standards process back then, but I would imagine you can't do this because of the browsers, not anything prohibiting it in the standards.Unknownhttps://www.blogger.com/profile/11697889068737143627noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-78539481375989320162010-11-26T20:47:58.079+07:002010-11-26T20:47:58.079+07:00The essential issues with XML and the Web are, as ...The essential issues with XML and the Web are, as far I can tell, historical and largely to due with poor process at the W3C. <br /><br />For example: why can't I use CSS with XML to do everything HTML can do? Why is an "a" tag still the only way to do a link in a browser with pure markup? And the answer is...because the CSS people won't go for it. Or so I've been told.<br /><br />If XML had been usable on the web a decade ago, in a simple fashion that easily transitioned from CSS, we wouldn't be seeing the HTML5/JSON approach James discusses. The XML technologies in the browser would've matured appropriately.<br /><br />I worry about the HTML5/JSON approach, frankly. I've talked to a lot of people on both sides of the fence, and the XML people's answer is, "Well, guess we lost that one." <br /><br />The HTML5 people, on the other hand, appear largely ignorant -- not just of XML's benefits, but of real programming basics. e.g. I heard, not so long ago, a rep for HTML5 claim that it's just as easy to write an HTML parser as it is an XML parser...which is ludicrous hooey, but it's the kind of garbage people are swallowing. Given the mess the HTML5 standards process has been, I suppose I shouldn't be surprised...Ben Traffordhttps://www.blogger.com/profile/10822392620101203055noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-89854356029266495892010-11-26T15:56:28.873+07:002010-11-26T15:56:28.873+07:00If the "new" Web is all HTML5/Javascript...If the "new" Web is all HTML5/Javascript/JSON, where does ATOM/RSS fit in to this model, will there be a new format with curlies instead of angled brackets?Anonymousnoreply@blogger.com