I’m currently writing some C# code that outputs RDF/XML from a set of classes, and came across some annoyances regarding .NET’s support for XML namespaces (or the lack thereof).
First of all, .NET has only explicit support for one namespace per element. Additional namespaces must be specified by adding an extra xmlns attribute yourself. Well, that’s not so bad, but it adds to the code bloat.
When you want to use namespaces to create new elements (e.g. rdf:Description), you have to explicitly pass the namespace URI again. Otherwise the prefix (in this case rdf) will be ignored. It would be helpful if .NET could check to see if the prefix corresponds to any namespace previously specified in the document root.
Okay, I could have used an RDF library, but this was supposed to be a quick hack, so I didn’t have time to learn another library.
I can’t help but think that if I would have just used strings instead of the System.Xml classes, the program would have been finished sooner. Come to think of it, I should have known better and just used N3 or Turtle.
When using .NET’s XML classes, it seems like half of my code is redundant. Man, do I miss Ruby‘s XML Builder.
I’ll end with a great graphic by Why the Lucky Stiff, in which he compares using XML to doing annoying sit-ups:
The term XML sit-ups also appeared on the Ruby on Rails homepage:
Rails is a full-stack, open-source web framework in Ruby for writing real-world applications with joy and less code than most frameworks spend doing XML sit-ups.
The common idiom with dynamic languages is to write configuration scripts or domain-specific languages in the language itself, instead of using XML. Compared to e.g. Java, XML is more agile and flexible, but that is not the case with dynamic languages such as Ruby or Python. XML.com has an interesting article about this issue.