Tagged with XML
Few five years olds have had as much impact as our little XML has these last few years. What started out as just structured storage as really changed into computer technology.
W3C has done a great job is helping get all those standards moving. Several years ago, I never thought that XSLT would ever become a standard. Add in the impending XQuery, XForms and their brethren, I think XML is headed in the right direction.
When I first read the SOAP specification I could not decide whether it was meant to be a replacement for DCOM/RPC or whether it was a messaging protocol. I loved the fact that the ligua franca of SOAP was XML. But at the same time, Section 5 supported the RPC view of SOAP. Unfortunately this section seemed to just confuse the issue between the RPC world and the document/literal world.
In a great MSDN Article, Tim Ewald argues against support for Section 5 support. I guess I haven't been keeping up, but I am excited to hear that Section 5 support is now optional in SOAP 1.2 specification. Yeah...but will Section 5 really ever die?
As I started playing with .NET's Web Services Framework some years back, I was excited and dishearted at the same time. It supported doc/literal by default, but it seemed to want to hide the fact we were using XML in any fashion. How unfortunate.
When the XML revolution happened, I was surprised how quickly developers jumped on to the coming tide. I have to admit, the first time I saw XML, I believed it was nothing more than just structured storage. That is the magic of it, isn't it. It is just structured storage, but a structured storage format that is universally understood.
So I think we have reached a crossroads with XML. The toolsets have made it so easy to use that I think there is a bit of overuse of XML. Afterall, XML is just structured storage, but it is inefficient structured storage. When we use XML we are giving up performance and efficiency for the portability of the format and the richness of tools to work with it (the tangential technologies of XPath, XSLT, SOAP, etc.). I like to think of XML as a way to enable enterprises to speak with each other in a common way. With that in mind, are we not (as developers) overusing XML? I think so.
How does this affect my daily work? I have come to realize that there has to be a better way of dealing with XML to improve the speed of development and simplify code that uses it. Using SAX or a DOM model to navigate XML documents creates spagetti code of weakly typed code. There has to be a better way of marrying portability of XML with a simplier (preferrably strongly typed) way of programming against XML. Luckily for those of us using .NET, the Framework's XmlSerializer class is a really useful tool in that it can allow us to use a set of classes as an object graph and only deal with the complexities and inefficiency of XML when we actually serialize it to an XML Document. See http://msdn.microsoft.com for more information on how to use XmlSerializer.