XML developers

We're using XPath on my current project and it's not something that I've used since 2000. Back then, Xerces and Xalan were separate Apache projects and I don't think JAXP was available. If you've not seen it before, XPath is a useful little language that you can use to retrieve nodes from an XML document based upon an expression that lets you match nodes and their content as you traverse down the DOM tree. You can also do other stuff, such as perform simple node set comparisons that return boolean results.

Back in 2000 when I used XPath for the first time, it was all so easy. DTDs weren't in regular use and I don't think we'd even considered using the concept of namespaces. Our XML documents were just that - very straightforward with a few angle brackets here and there. Well-formed, but not necessarily valid.

Step forward a few years and it's a different world altogether. Now we have XML Schema, namespaces and the emphasis is on making sure systems interoperate correctly by using valid XML that makes use of namespaces to mix together elements from different schemas.

It used to make me laugh when I saw the term "XML developer" but there's definitely a niche for being just more than a [Java|.NET|etc] developer with some casual skills in the use of XML. Throw web services into the mix and you've got a full-time role just taking care of the XML stuff on your project. Aren't all these standards supposed to make our lives easier?

Tags :
Responses[3] RSS feed for responses to this blog entry
Posted by Simon Brown on 13 July 2006 09:29:38 BST #


Reply

Re: XML developers

Comment from Alex Blewitt on 13 July 2006 12:27:02 BST #
Half of the time, the problem is in the APIs and all the hacks/hooks that you have to go through to convince the underlying layer why it's necessary to use namespaces. On the other hand, if you use a tool like XOM, then it's really very easy (provided that you know what namespaces are). You simply add the namespace and the binding, and then your XPath expressions match whatever namespace is being used in the document. Personally, I think it's great -- it allows you to mix content e.g. XHTML in an Atom feed, and then process just the Atom stuff with Atom:* (assuming you've bound Atom to the correct namespace in your query). XPath in XOM is really very easy; I don't think there's any reason why people shouldn't be able to use it out-of-the-box. It's also got very good XSLT support, and it's an API designed for programmers, not for specs sake (unlike, say, Schemas).
Reply

Re: XML developers

Comment from Dan Creswell on 13 July 2006 12:43:41 BST #
I suspect the complexity you're seeing is down to the same behaviour as we see in such things as frameworks.  There's always a big drive to make something more generic, which means more options and potentially more need to handle corner cases.  Which ends up meaning more complexity.

The one size fits all mentality is alive and well and it seems like we still haven't learnt that it's a double edged sword of increased coverage versus greater complexity.  Ironically, I suspect that greater complexity potentially means that we use something less often simply because we can't get to grips with it which in turn renders all those additional features pointless and costly.

Ruby on Rails is kind of interesting in that respect.  It's started from the position of doing a narrow task well but there's increasing pressure to cover more corner cases and expand functionality.  Rails has rough edges but it's still got a nice balance of utility versus complexity - it's good enough.  It'll be interesting to see if it remains this way over time.
Reply

Re: XML developers

Comment from Simon Brown on 13 July 2006 14:42:00 BST #

It reminds me why people use REST and XML-RPC rather than web services. If you want to deliver a service in a platform independent way, why go to all the trouble of using SOAP et al.

Good observation on Rails, it will be interesting whether it stays focussed or turns into the next J2EE.


Add a comment Send a TrackBack