Live data from Hacker News

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

hsivonen.fi

81–90 of 255 posts

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

#81
post #76
post #42

Earlier quoted context omitted.

> 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…

I think the worst of this is what I call semantic incoherence. I have a system that has things like Blah . Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string? Another favorite: [CDATA[Batchfile.bat]] , while a binary or something else will be "program.exe /argument:f /argument2:x" . By the way, this is an enterprise as it gets: a software tool from a four-letter hardwa…

> Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string

Becase XML is a text-based markup. If you truly want binary data you need to encode it and use CDATA sections.

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

#82
post #3

Back in the early days of XML, Internet Explorer would insert "+" characters to fold nested sections of XML. And was the default program to open .xml files. Guess what showed up in the documents I got from an integration partner?

I once got an XML file from an integration partner where the whole thing was XML escaped (all the tags looked like <node>value</node>) because they had embedded it within an outer "envelope" XML file. They saw nothing wrong with this and argued when I questioned it. I wonder how they were planning to express escape sequences within the inner XML document that was already escaped...

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

#83
post #42

Earlier quoted context omitted.

> 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.…

XML could be fairly lightweight also. It was all the enterprisey-standard formats that were hideous.

E.g.

    {"name":"John","age":42}
vs.

    

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

#84
post #81
post #76

Earlier quoted context omitted.

I think the worst of this is what I call semantic incoherence. I have a system that has things like Blah . Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string? Another favorite: [CDATA[Batchfile.bat]] , while a binary or something else will be "program.exe /argument:f /argument2:x" . By the way, this is an enterprise as it gets: a software tool from a four-letter hardwa…

> Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string Becase XML is a text-based markup. If you truly want binary data you need to encode it and use CDATA sections.

That was not quite my point.

Why pretend it is a string at all?

3

I should have been more clear. Sometimes you have these argument type deals where I would at least hope for or the monstrosity above (I assume ID=3 is not valid in hindsight, I am getting tired just writing this all on the second pass even!). And I see all different variations in the same XML file! There is no logical consistency, not even in the same config for the same function of this multi-stage system.

I am not even a novice programmer, and I find the variation annoying, and sometimes hard to reason about when I want to know what the hell the programer was thinking.

The valid part for the CDATA portion has changed several times in minor releases, so when our server team upgrades, I get to figure out the new syntax.

I thought XML was proposed to avoid these things! Haha. Again, tools in the hands of "wise men" like me are dangerous. I am probably as ignorant as them, I just think I know better!

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

#85

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

If you're actually marking up text, JSON doesn't really work. XML works alright for its intended use as a language. (That doesn't mean I hate it any less.)

I think if you're marking up text, you really want to be using markdown one of the other wiki like formats. For writing you're much more likely to run into non-technical people who will be severely impacted by syntax errors.

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

#86
This article in some ways describes the delta from HTML development to XML development. In the early/mid 2000s, XML was cargo-culted through the tech world on a massive scale; typically being adopted by web developers who proceeded to apply the same habits and tools for XML as they'd been using for HTML. Which of course resulted in many of the issues mentioned.

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

#87
post #77

> Don’t print > Use an isolated serializer Some old reference material (XML isn't as common as JSON anymore), but still worthwhile learning: don't output data formats directly. Directly = echo, print, printf,println...whatever your syntax suggests. I see this happen a lot with my junior engineers, and I have this same conversation with them. Prefer to use data serializers that encapsulate all the syntactical rules th…

i think a major problem is that XML kinda looks and feels like HTML (and there was the whole XHTML thing to further confuse), and outputting HTML programmatically (vs string / print / template based) has most been frowned on as overweight and cumbersome. you come from web dev doing HTML like that and you see XML and think "hey, that looks the same, i'll do it in the same way". XML is a programmatic data exchange form…

>YAML, which most people would never think of outputting as templates

Don't tell the Ansible folks!

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

#88
post #42

Earlier quoted context omitted.

> 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.…

I agree, especially with the easy to understand part.

Look how short the standard is: http://www.ecma-international.org/publications/files/ECMA-ST... It's small and perfect, like a 2x1 LEGO block.

Here's the XML spec: https://www.w3.org/TR/REC-xml/

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

#89
post #83

Earlier quoted context omitted.

> 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.…

XML could be fairly lightweight also. It was all the enterprisey-standard formats that were hideous. E.g. {"name":"John","age":42} vs.

Now do the nested objects in both. One line does not show much.
Post reply on HN