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

171–180 of 255 posts

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

#171

Post by int_handler »

bane wrote: post #110

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

I'm sure you will also love JSONx: http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com....

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

#172

Post by int_handler »

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…

My impression is that the reason why XML is so well-regarded in the enterprise is because these companies are not aware of better alternatives, such as Protocol Buffers [1]. The reason why XML has a bad reputation outside of the enterprise is because it is so incredibly verbose (both the language itself and the code used for working with it), and that all-in-all, it is a sub-optimal solution to a solved problem.

To illustrate: Protocol Buffers' wire format is much more compact. It removes the complexity of having to deal with XML parsers by providing classes generated from the message definition/schema. You can use it with GRPC to implement your service APIs. It is supported for many different languages, including Java and C#. It now even has a JSON mapping [2]. Overall, Protocol Buffers can do everything XML can do as both an exchange format and as a configuration language but better.

[1] https://developers.google.com/protocol-buffers/

[2] https://developers.google.com/protocol-buffers/docs/proto3#j...

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

#173

Post by bane »

int_handler wrote: post #171
bane wrote: post #110

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

I'm sure you will also love JSONx: http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com....

There....that's a perfect example. Thank you.

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

#174

Post by ivl »

flukus wrote: post #148
SomeCallMeTim wrote: post #125

Earlier quoted context omitted.

>In those cases, I would rather have XML config files than undocumented binary blobs as config files. False dichotomy. Better than XML and binary blobs: * JSON (assuming everyone knows what this is) * YAML [0] * Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all) * INF format [1] (not my favorite, but pretty easy to parse and much better for humans t…

> JSON (assuming everyone knows what this is) The new .net uses json, it's awful. No comments allowed and it get's pretty unreadable when you have nested configuration elements.

I seriously think the lack of comments is a deal breaker for JSON config files for me. At least with what I'm doing now. I find myself changing configs a ton, and I love being able to simply change which blocks are commented to get what I want, without having to dig anywhere.

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

#175

Post by flomo »

saurik wrote: post #70
djur wrote: post #64

Earlier quoted context omitted.

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…

My experience with early Ruby XML parsers is that they were all "how hard can this be?" hacks someone did over a weekend by people who didn't really use XML or understand the ecosystem of specifiations and thereby barely worked and often didn't support fundamental things like namespaces correctly. It took away everything which made XML powerful and left you with something that was often even finicky.

Yeah, I worked on a Rails 1.x app which integrated with an xml feed. IIRC, the options were a library that used regexes internally and had horrible performance (but might have been fine for rss feeds), and another library which wrapped a C library and used callbacks[1]. Definitely was a huge pain point and probably was a mistake for me to use the latest hep environment for that app, but for the rest of Rails it might have been worth it.

[1] I think it might have been http://www.yoshidam.net/Ruby.html#xmlparser

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

#176

Post by int_handler »

SomeCallMeTim wrote: post #125
mwfunk wrote: post #121

Earlier quoted context omitted.

I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly vs. using other tools or APIs to touch the file. In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a bin…

>In those cases, I would rather have XML config files than undocumented binary blobs as config files. False dichotomy. Better than XML and binary blobs: * JSON (assuming everyone knows what this is) * YAML [0] * Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all) * INF format [1] (not my favorite, but pretty easy to parse and much better for humans t…

You can use Protocol Buffers for configs without having to serialize them in its binary format. Protocol Buffers has always had its own text format [0] and now a JSON mapping [1] as well.

The proto text format is actually more flexible and less verbose than JSON since it does not require the outer enclosing set of braces and quotes around all the keys and has support for comments.

Here are a couple of examples of config files using the Protocol Buffers text format:

* Bazel CROSSTOOL: https://github.com/bazelbuild/bazel/blob/master/tools/cpp/CR...

* SyntaxNet: https://github.com/tensorflow/models/blob/master/syntaxnet/s...

[0] https://developers.google.com/protocol-buffers/docs/overview...

[1] https://developers.google.com/protocol-buffers/docs/proto3#j...

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

#177

Post by popmystack »

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…

>Why pretend it is a string at all?

You are confusing the language and underlying datatypes, which is extremely ironic given the criticisms levied against XML in this thread.

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

#178

Post by einhverfr »

lttlrck wrote: post #147
einhverfr wrote: post #25

Earlier quoted context omitted.

Yep. As I usually say, it is better to be able to say "not my problem" than it is to be able to say "invented here." The single greatest strength of a skilled software engineer is to know when to make it someone else's problem.

Even if it is not your fault it can still be your problem.

Which is why judgment in that question is so valuable.

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

#179

Post by einhverfr »

cptskippy wrote: post #165
einhverfr wrote: post #34

Earlier quoted context omitted.

XML is very often the least bad format (compared with ASN.1, JSON, X12 EDI, CSV, and other interchange formats), particularly when dealing with statically typed languages. XML is a horrid chimera of SGML but at least it is both human readable, subject to machine validation, and gets the job done.

Oh EDI... you made me shudder.

No experience with ASN.1?

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

#180

Post by brightball »

bane wrote: post #158
brightball wrote: post #141

Earlier quoted context omitted.

The biggest advantage of XML was the detailed schema validation. Having a uniform and flexible way to both generate data structures and ensure that their contents was valid before ever attempting to process them was handy. XML had a lot of warts but most of its strengths are still seeking passable implementations in JSON. Protocol Buffers is probably the closest thing to being standard in that area for schemas and ge…

Yeah, I acknowledge that bit. But I also think the various schema definition languages (DFDs, XSD, whatever) turned out to be either not expressive enough (DFDs), or a complete PIA (XSD) and in the end, they weren't used very often. Still, it's nice to have them when you need them and when they aren't there it hurts.

I'll definitely agree with that. I remember using some Java desktop GUI to generate XSD's rather than typing all that stuff out.
Post reply on HN