Live data from Hacker News

How to Avoid Being Called a Bozo When Producing XML (2005)

hsivonen.fi

51–60 of 255 posts

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#51

Why would anyone choose to use XML over JSON, other than for RSS?

I can parse/print XML (using either in memory parser or streaming parser), use XML Schema to validate XML, XPath expressions to select necessary parts, automatic object mapping, and that's all with standard library without a single external dependency in Java. I don't know why would I use JSON over XML, unless I have very good reasons to do so. For me the only thing that JSON got better is that JSON is directly mappe…

> For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps.

This is nice, but it's also kind of a pain, as it makes you have to stop and think about which structured data elements it's capable of supporting and which you have to send your own metadata through the wire and then reconstruct on your own. For example: Dates. Which is a shame. If there is one data element I want the most help with serializing/deserializing, it's freaking Dates. All the other ones are super easy in comparison. There's just way to much subjective, dirty, human culture tied up in Dates.

The only thing that I think is objectively better in all cases about JSON over XML is the less verbose end-structure syntax. I think XML only has Attributes because Tags have this silly need to state their name both as they enter and exit the room.

    
      how
      are
      you?
    
For simple, unnestable data elements, having the more efficient Attribute starts to look attractive.

If XML were more the form:

    
      how
      are
      you?
    
It's actually only one more additional, required character to add than if the attribute value were specified as an element instead.

    
      hello
      world
      how
      are
      you?
    
Heck, why stop there? Do we really need to have quite all of those angle brackets now? How about we just get rid of all the ones we can assume:

    
      
      
      
      
    >
And finally, who even likes angle brackets? I've never enjoyed the dual duty they play as delimiters in XML and operators in other languages. Let's use a common set delimiter, something like square brackets or maybe parentheses.

    (Tag1
      (attr1 hello)
      (attr2 world)
      (Tag2 how)
      (Tag2 are)
      (Tag2 you?))
Now where have I seen this before?

PS: JSON that is as nearly as equivalent as I can make it is not much less verbose than original XML, and requires some level of convention to make up for the differences:

    {Tag1: { attr1: "hello", attr2: "world", children: [
      {Tag2: "how"},
      {Tag2: "are"},
      {Tag2: "you?}]}
Though I'm sure in common practice it'd have a lot of the original metadata of the XML version thrown away:

    {attr1: "hello", attr2: "world", children: [
      "how",
      "are",
      "you?"]}

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#52

Earlier quoted context omitted.

I can parse/print XML (using either in memory parser or streaming parser), use XML Schema to validate XML, XPath expressions to select necessary parts, automatic object mapping, and that's all with standard library without a single external dependency in Java. I don't know why would I use JSON over XML, unless I have very good reasons to do so. For me the only thing that JSON got better is that JSON is directly mappe…

> For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps. This is nice, but it's also kind of a pain, as it makes you have to stop and think about which structured data elements it's capable of supporting and which you have to send your own metadata through the wire and then reconstruct on your own. For example: Dates. Which is a shame. If there is…

[deleted]

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#53
Compared to the problems when dealing with 'delimited text', XML is great.

Also it's flexible where you can specify properties as attributes or child nodes, depending on wildcard specifications.

So I have dealt with lots of edge-case XML situations, but the solutions are always straight forward. Also it helps to have a client vs. trying to parse out raw XML, which means programming and scripting sometimes relies on personal tool development. XML handles scope creep well.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#54
post #30

Why would anyone choose to use XML over JSON, other than for RSS?

XPath expressions are actually pretty cool (and I say this as not a great fan of XML in general). The ability to search and select elements is something we use all the time. For many examples, search for "xpath_" in https://github.com/libguestfs/libguestfs/blob/master/v2v/inp...

I'd drink to that, XPath is incredibly useful and easily mastered.

I'm also fond of XSD and XSLT myself. They can be obtuse at times, but have been indispensable in the use cases that I've needed them for.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#55

This reminds me of an interesting experience I had with XML at a pervious job a few years ago. We had bought a product from another company which was to be integrated into our own main product. Theirs was horribly ugly, looking like a cross between a 90's website and an infomercial, predominately in vivid shades of pink and purple. And it was really buggy. I soon noticed that all the content (many hundred pages with…

Please edit your post to eliminate the fixed-text:

- It will be easier to read.

- Reading won't require a lot of fiddly trackpadding.

- Maybe it would be nice if HN's simple markup system could handle the case in which the author wants a list of indented items, but it doesn't, and fixed-text is a poor substitute for that.

[EDIT:] Thanks!

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#56
post #2

Had to post this old article because I encountered some bozo code again. Reading more about some CMS and planning on using it for my blogs when I saw the code of the RSS feed. It was written by the lead developer of the CMS and used text templates.

The way your comment comes across is a bit irritating. Not understanding the underlying codebase and classifying based on an attenuated knowledge of a topic promotes one to the 'bozo' status more quickly than not. Many systems use text-template based feeds, examples are Shopify, Salesforce, Wordpress, and more. Are these systems fundamentally broken purely because of this approach? Probably not. In your case, are the…

You mention typical PHP projects written by people who think they know better than the likes of Tim Bray.

PHP, the language that made short tags a configuration option because they wanted to mix program code with XML.

PHP, the language with a lot of different escape functions because they didn't get it right the first time.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#57

This reminds me of an interesting experience I had with XML at a pervious job a few years ago. We had bought a product from another company which was to be integrated into our own main product. Theirs was horribly ugly, looking like a cross between a 90's website and an infomercial, predominately in vivid shades of pink and purple. And it was really buggy. I soon noticed that all the content (many hundred pages with…

Please edit your post to eliminate the fixed-text: - It will be easier to read. - Reading won't require a lot of fiddly trackpadding. - Maybe it would be nice if HN's simple markup system could handle the case in which the author wants a list of indented items, but it doesn't, and fixed-text is a poor substitute for that. [EDIT:] Thanks!

There. I agree, it looked horrible

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#58
post #42

XML is well regarded in the enterprise and languages like JAVA, C#, and VB.NET handle is spectacularly as an exchange format. I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. I recall working with a partner who we were doing an identity federation with. Our system was using WS-Trust which is a SOAP/XML protocol. It wasn't ideal but everyone seemed to…

> I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. On the contrary, I think that XML's bad reputation comes from the fact that it is so incredibly verbose . Also, the whole child/attribute dichotomy is a huge, huge mistake. I've been recently dealing with the XDG Menu Specification, and it contains a child/attribute design failure, one which would ha…

> JSON has become popular because a lot of bad programmers saw nothing wrong with calling eval on untrusted input (before JSON.parse was available).

Disagree. JSON became popular because it was extremely easy to implement (both for marshaling and consuming), and because it was extremely lightweight.

I think you could also make the argument that JSON was conceptually easier for programmers to wrap their minds around. You could just pretty-print it and quickly get an idea for the object's format, attributes, etc.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#59

Earlier quoted context omitted.

I can parse/print XML (using either in memory parser or streaming parser), use XML Schema to validate XML, XPath expressions to select necessary parts, automatic object mapping, and that's all with standard library without a single external dependency in Java. I don't know why would I use JSON over XML, unless I have very good reasons to do so. For me the only thing that JSON got better is that JSON is directly mappe…

> For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps. This is nice, but it's also kind of a pain, as it makes you have to stop and think about which structured data elements it's capable of supporting and which you have to send your own metadata through the wire and then reconstruct on your own. For example: Dates. Which is a shame. If there is…

The XML tag style is much, much easier to work with when you're dealing with markup. And XML's purpose is to be an Extensible Markup Language. It's way more appropriate than JSON or S-expressions for that.

(Do you prefer to write HTML documents as S-expressions?)

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#60
post #28

The author of this post is a bozo, doing any (or not doing any) of the suggested things does not guarantee well formed XML. Disregarding whole sections of the XML spec, prescribing a certain way to generate xml are more harmful than not. Can text templates generate well formed xml, absolutely. Can tools generate non-well formed xml, absolutely.

> Making mistakes with them is extremely easy and taking all cases into account is hard. He states why right there. He doesn't say anywhere whether templates can or cannot generate well-formed xml.

(I'm the author of the article.)

Today, it's clear that text/html has won over application/xhtml+xml and JSON has won over XML for most (non-enterprise) non-document uses. But back around 2003..2009, there was no shortage of people who advocated in favor of XML and got it wrong when writing it by hand or when generating it with text-based templates.

Philip Taylor (not to be confused with Philip TAYLOR) was one of the regulars on the #whatwg IRC channel around 2007..2009. He had a hobby of trying to get XML advocates' systems to produce ill-formed output. He pretty much succeeded every time. IIRC, he even found a bug in Validator.nu's XML output, even though Validator.nu practices what I preach in the article.

The easy way was to supply user input that contained U+FFFE and watch the output blow up with the Yellow Screen of Death when U+FFFE was echoed as-is. Unless you have a templating system designed with the warts of XML in mind, this will happen. (A proper XML serializer has to scrub the characters that aren't allowed in XML, as seen in https://hg.mozilla.org/projects/htmlparser/file/dd08dec8acb7... .)

He even found a bug in Tim Bray's code that was written to make the point that it's possible to generate XML correctly... (https://lists.w3.org/Archives/Public/www-archive/2009Mar/006...)

Post reply on HN