The Sins of XML
In case you didn't notice, I don't like XML. To be rather exact, I don't like the way XML is used. If you are writing a document, it is a great way to skip parsing headaches, but seriously, is writing a parser that hard?
Case in point, SSIS packages are just XML, but they are literally binary XML, in that I have no way of really looking inside and figuring out what is going on. Oh, I can probably put it through a prettifier and then try to have a look-see, but that is a costly endevour, and not really practical for anything beyond getting the bloody connection string out of the file.
Just today I was looking at SSIS package, it was changed, but I have no idea what the change was, so I run a diff. It came back with a lot of changes, non of which told me, an occational (reluctant) dabbler of SSIS what the hell had happened.
Just this, the inability to understand what the hell has changed from a diff file, is a serious offence against the maintainability of most of the "no code" approaches (but reams of XML).
Urgh!
In other news, Boo got better support for creating DSLs.
Comments
I would agree with you in principle but you chose a bad example. DTS packages were pure binary. You are better off with binary-ish XML even if it's hard to read.
I don't think the point of XML is whether writing one parser is hard. It's that writing a new parser every time you want to exchange data with someone or want to manipulate the config of another program, etc. is a pain.
If you write custom language/custom parser instead of using XML, you immediately lose: XPath queries, XSL transformations, XSD validation, xml reading/writing facilities in all major languages/frameworks.
Also, when XML is used correctly, diff is easy to read (I never had problems understanding changes in *.csproj files).
Well, for a DSL lang, do you really need XPath, XST, etc?
*.csproj is an xml _document_, that is the way it is suppose to work. I am talking about the executable XML stuff. SSIS, BizTalk files, etc.
Ok, I have never seen an SSIS file so I do not think anything about it.
But for files from BizTalk, SSIS and other provided formats, XML is nice since it gives people who do not have the original language processor way to work with/extend these files.
For example, it is harder to forbid XInclude in XML than to create DSL that does not support file import at all. Also, if the original vendor didn't thought about any Intellisense, it is much easier to create XSD than to write a language service. Same for the case when you want to validate file generated by a tool.
@Andrey,
That assumes that you have a fully complaint parser on the other end, which is not always a valid assumption. See my next posts for the details.
Comment preview