Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hsivonen.fi

Post reply on HN
Print view View original

101–110 of 255 posts

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

#101

Post by colejohnson66 »

thangalin wrote: post #95
616c wrote: post #84

Earlier quoted context omitted.

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…

What takes fewer lines of code to parse? Or accepting both: How would you specify an empty value for mandatory attributes?

I've seen empty values written as

    data
Whether that's legal or not, I don't know.

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

#102

Post by legulere »

wtbob wrote: post #42
cptskippy wrote: post #18

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…

The problem is that XML maps badly to data structures in common programming languages. JSON maps perfectly to structs and datastructures as lists/arrays/maps.

S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. I also can't see how they map easily into datastructures of imperative programming languages or even statically typed functional programming languages like haskell.

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

#103

Post by ambrop7 »

cptskippy wrote: post #18

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…

Some time back I needed to generate an XML file in a Java web application. I attempted to figure out how to do it "right". The only "special" requirement was that it is formatted in a readable way.

So I was figuring out the Java XML stuff (don't remember what that was exactly, probably standard). But at some point the timeout in my brain kicked in, and I just wrote a loop generating the XML by brute-force through PrintWriter or something. I even escaped strings right since some library I had available conveniently offered the escape method (Guava maybe?).

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

#104

Post by MichaelGG »

_greim_ wrote: post #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.

There's a popular piece of "newer" software that decided that XML rules were too difficult. So they URL encode all values. It also uses print style formatting for XML tag names, so if you manage to get a name value that has, say, a : in it, you'll get invalid tags. This is the default setup, in 2016, for a system that handles a lot of real-world telephone calls.

Even just a few years ago I've worked with companies that wrote their own "XML parser". They explained it was pretty easy but they had to "special case" for broken output in the real world. An example of this output? "".

HTML would have been far better off if it had the strictness of XML. Remove end tag names so you can't have invalid nesting. If browsers had refused to parse invalid docs from the start, invalid docs would not have been produced. (And like XML, they could provide decent error messages, so the difficulty would not be significantly raised.)

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

#105

Post by MichaelGG »

wtbob wrote: post #42
cptskippy wrote: post #18

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…

XML's bad rep for verbosity is almost entirely due to the nonsensical, terrible idea of requiring names in the end tag. Without that, it's about the same level of verbosity as JSON. And personally, after writing plenty of both by hand, XML is easier to get right. JSON, with it's poor quoting rules (mandatory quotes on names??) and lack of comments is very annoying to do by hand and seems visually more noisy.

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

#106

Post by oceanswave »

616c wrote: post #84
ams6110 wrote: post #81

Earlier quoted context omitted.

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

Enclosing the attribute within double quotes isn't pre-disposing the value to be of a particular type. It's part of the XML spec that attribute values are contained within double quotes, and must be to be valid. The type isn't implied in the file.

An xml schema such as

could more explicitly declare the type of the value.

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

#107

Post by oceanswave »

colejohnson66 wrote: post #101
thangalin wrote: post #95

Earlier quoted context omitted.

What takes fewer lines of code to parse? Or accepting both: How would you specify an empty value for mandatory attributes?

I've seen empty values written as data Whether that's legal or not, I don't know.

not valid. wondering if you've seen that within HTML, where it is valid.

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

#108

Post by JoshTriplett »

wtbob wrote: post #42
cptskippy wrote: post #18

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…

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

Those two factors run counter to each other. Attributes decrease verbosity, compared to child elements.

I agree, though. A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags (value), which makes child elements much less verbose, and reduces the need for attributes.

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

#109

Post by [deleted] »

djur wrote: post #64
cptskippy wrote: post #18

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…

Ruby has had an included XML library since before Rails was released. soap4r is older than Rails too. I wrote my share of clients for SOAP services back then. soap4r wasn't fun to use but it mostly worked. If the service was really simple (a single call and response, for instance) it was sometimes more expedient to put together the request yourself. When Savon came out 6-7 years ago it was a huge relief. Luckily, by…

[deleted]

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

#110

Post by bane »

My "favorite" XML formats are the one that are just some kind of weird meta-format and don't really use any of the XML features:

   
      
         
         blah blah
         this is the attribute value
         
      
      
      ...
And yes, these types of abominations are everywhere.

The only way to avoid being called a Bozo when producing XML is to either

a) ensure that humans never had to see this craziness

b) don't use XML

XML as a config file format, in particular, is probably one of the worst ideas in computing.

Post reply on HN