Comments on: All markup ends up looking like XML https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/ Open information and technology. Thu, 04 May 2023 11:10:06 +0000 hourly 1 http://wordpress.com/ By: The Move to JSON – FaulknerMigrate https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-34089 Thu, 04 May 2023 11:10:06 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-34089 […] 1 David Megginson. "All Markup Ends Up Looking Like XML." January 2007. https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/ […]

]]>
By: Groovy Object Notation (GrON) for Data Interchange | T. C. Mits https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-4138 Sat, 06 Oct 2012 13:30:21 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-4138 […] “All markup ends up looking like XML“, https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/ […]

]]>
By: Oliviero https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-4099 Thu, 24 May 2012 17:35:32 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-4099 In reply to Chris Nokleberg.

Masklinn: you’re right that my examples were not very ceiclmpatod and could have been represented more simply in all three markup syntaxes see Crockford’s comment earlier, which made the same point as yours.Just to throw a wrench into it, though, you cannot always assume that order doesn’t matter. For example, try this:Saddam HusseinIf you break this down to a map then try to reconstruct the name, you’ll end up with Hussein Saddam instead of Saddam Hussein . The solution then, of course, is to add *another* property specifying whether the surname comes first or last.Next, you see a name like this:James Fitzwilliam Godwin IIIA simple ordering property won’t work now. Instead, for your map, you’ll have to include a surname, pre-surname, and post-surname property. And then you have the problem of honorifics, which can come before ( Dr. , Sir ) or after ( PhD , OBE ) the name, or prepositions like de in French and Spanish, which go with the surname but drop off for collation, etc.I think most people who work with real, non-trival data have experienced these kinds of problems, even when XML has never entered the equation notice how relational database schemas in production systems usually end up resembling a ball of tangled string more than the neat diagrams in textbooks.

]]>
By: Castino https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-4096 Thu, 24 May 2012 09:10:51 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-4096 In reply to rektide.

finally can append to it but the type atruibttes 1 will write to the tag once i re-run the program Is that any way where it will continue the numbers instead of starting from 1 .Currently Xml file: ok1no2 Not I wanted Peter7 Hope to become: ok1no2 This is what I wanted Peter7 My Coding:Dim m As String = 1 Private Sub btnAdd_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnAdd.Click Dim doc As New Xml.XmlDocument load file doc.Load( data.xml ) Dim root As XmlNode = doc.SelectSingleNode( //Books ) If root Is Nothing Then if this is a new document create root root = doc.SelectSingleNode( //Books ) Else create node get root node named users Dim Usersnode As Xml.XmlElement = doc.SelectSingleNode( //Books ) add the new node Dim newNode As Xml.XmlElement = doc.CreateElement( Book ) add atruibttes newNode.SetAttribute( type , m) add children nodes if any Dim child As Xml.XmlElement = doc.CreateElement( Author ) child.InnerText = txtAuthor.Text newNode.AppendChild(child) child = doc.CreateElement( Section ) child.InnerText = txtSection.Text newNode.AppendChild(child) add new node to users node Usersnode.AppendChild(newNode) m += 1 End If save doc doc.Save( data.xml ) End SubThanks Was this answer helpful?

]]>
By: Notes on document-oriented NoSQL | DBMS 2 : DataBase Management System Services https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-3637 Mon, 07 Feb 2011 08:51:29 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-3637 […] One good starting point for recent JSON vs. XML discussion is here. My favorite from the 2007 iteration of the debate is this one. […]

]]>
By: Me, myself and I https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-3369 Thu, 26 Aug 2010 13:14:18 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-3369 My personal experience with JSON and XML is with RPC calls from the browser to the server. Such calls never happen using simple argument lists, but structures. A responsive web application is not allowed to be chatty, and the best way to achieve this is not to do few complex calls instead of many simple calls. Complex calls rely on complex arguments. Once the data structures you encode become large and complex, both JSON and XML become increasingly hard to use. The only helpful thing in XML is that if you bothered to design a schema (which you won’t, in most cases), you’ll get a much earlier warning from the parser, whereas a bad data structure makes it up into the processing code when using JSON.

Other than that, JSON rocks. As Larry Wall puts it, “easy things should be easy and hard things should be possible”. That’s definitely the case with JSON. With XML, it’s more like “easy things are hard like hell, whereas hard things are next to impossible”. At least for RPC from the browser.

As for the scheme syntax: somebody (I think a speaker on google tech talk I saw on youtube) once said that Javascript is sort of a somewhat crippled Lisp with C syntax. Javascript is indeed a language in which you represent programs using the language’s own data structures, to a large extent – which is why JSON is so natural to Javascript. Which is probably why the scheme and JSON examples look so much alike.

]]>
By: Is JSON the Developers Choice? https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-3228 Wed, 11 Aug 2010 12:39:57 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-3228 […] I think David Megginson put it most succinctly: “Personally, I like XML because it’s familiar and has a lot of tool support, but I could […]

]]>
By: Andrzej Taramina https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-607 Wed, 28 Feb 2007 18:53:42 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-607 Might be worth considering HL Mencken’s thoughts on XML vs JSON vs LISP et all:

“We must accept the other fellow’s religion, but only in the sense and to the extent that we respect his theory that his wife is beautiful and his children smart.”

XML vs JSON vs LISP, that would be the “religion” part. 😉

]]>
By: Robert https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-606 Tue, 27 Feb 2007 02:32:17 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-606 >> Manually writing code to traverse them is tedious at best.

hmm. that’s why Dr. Codd devised the relational model. as one other commenter pointed out. folks may continue to stuff data into hierarchy, whether it belongs there or not. eventually, someone will “rediscover” that the magic of the relational algebra. sigh.

]]>
By: Bob White https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-605 Tue, 06 Feb 2007 21:56:28 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-605 Is there an equivalent to XPath for JSON?

]]>
By: Martins Notepad » Blog Archive » Markups raison d’être https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-604 Mon, 29 Jan 2007 17:22:29 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-604 […] Megginson posted a follow up on his earlier take on JSON, which contains an excellent example/explanation on the advantages of markup compared to hard wired […]

]]>
By: Megginson Technologies: Quoderat » Blog Archive » Thinking about structure https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-603 Mon, 29 Jan 2007 03:47:47 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-603 […] Crockford left an excellent comment on my recent posting All markup ends up looking like XML, which he later made into its own blog posting, For the trees. I agree with his reworking of the […]

]]>
By: Kristian Kristensen’s Blog » https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-602 Sun, 28 Jan 2007 22:50:45 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-602 […] Trees Are Better Than Others”, which implies you gotta read Megginson’s piece “All Markup ends up looking like XML” and Doug Crockfords comment on that last one “For the trees”, gets me thinking. JSON […]

]]>
By: david https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-601 Sun, 28 Jan 2007 12:50:31 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-601 Danny: The easiest approach would be simply to encode the triples in JSON. The only trouble is that, at least for RDF 1.0, the triples data model didn’t actually represent all of the information in the XML syntax. Maybe that’s been fixed in a later RDF revision.

]]>
By: Danny https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-600 Sun, 28 Jan 2007 12:31:33 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-600 Very nice comparison.

So here’s another challenge (should you choose to accept it 😉 Given “There is no information that can be represented in an XML document that cannot be represented in a JSON document”. Ok, we all know RDF/XML syntax is really ugly. So how would you do RDF in JSON?

(There are a few different systems which use RDF in Lisp, so that’s already covered. There’s also Turtle RDF syntax which is JSON-like in terms of simplicity, and I’m pretty sure Javascript browsers are available, but an eval() would be so much easier…)

]]>
By: del.icio.sfera » Megginson Technologies: Quoderat » Blog Archive » All markup ends up looking like XML https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-599 Sat, 27 Jan 2007 01:16:27 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-599 […] Vai alla pagina segnalata. […]

]]>
By: Aristotle Pagaltzis https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-598 Fri, 26 Jan 2007 04:24:51 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-598 I used to hate XML. Then I discovered XPath.

The funny thing is that XPath conversely is such a nice API for querying XML that now I find myself wishing I had it available for native datastructures. Manually writing code to traverse them is tedious at best. The CPAN has several modules that implement (some subset of) XPath for document types it was not designed for, even one that adds an XPath interface to regular classes so that you can use XPath to walk object hierarchies.

]]>
By: david https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-597 Thu, 25 Jan 2007 21:35:20 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-597 rektide: I think you hit on a major problem with XML in the browser — it’s not XML itself, but the DOM, which is an extremely awkward interface to use. Part of that is because DOM has to be able to handle mixed content as well as fielded data, but a lot of it is simply the DOM’s design history. Personally, I always use some kind of a simple helper library with browser-based DOM.

]]>
By: rektide https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-596 Thu, 25 Jan 2007 19:36:41 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-596 the thing I like about JSON is that it maps to a object oriented data structure, and the tooling surrounding it is just about serial/deserialization. in comparison, the DOM data structure used by XML is immensely frustrating to deal with. multiple text node children hanging off elements, content validation before you can .InnerText, theres just a never ending rigamaroll to do what is ultimately a very very simple task, and i for one do not enjoy writing such verbose kludgtastic code. the data structures built by xml tooling just suck horrendous ass.

i’m still unsure as to the ultimate feasibility, but projects like jsonml to bridge json and xml seem like they could be vital in the future. there’s a lot of xml out there already, but at this moment, i can say i would like very much to be able to ignore it for the rest of my days, and consume it as json.

]]>
By: Michael Speer https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-595 Thu, 25 Jan 2007 14:44:17 +0000 http://www.megginson.com/blogs/quoderat/2007/01/03/all-markup-ends-up-looking-like-xml/#comment-595 ‘( names!

( :name
:gender female
:lang it
:given “Anna Maria”
:sur “Mozart” )

( :name
:gender male
:lang en
:given “Fitzwilliam”
:sur “Darcy” )

( :name
:gender male
:lang fr
:given “Maurice”
:sur “Chevalier” )

( :name
:gender female
:lang de
:given 7.9
:sur NIL ) )

? The lisp can be made clearer, I think.

]]>