Missing the Cluetrain

Dare Obasanjo has a post about blogging discussions at Microsoft. With respect to Dare's first point, my employer's policy is basically that nobody can make public statements identifying themselves as an employee without getting official approval. In the past, I was told that when posting to a newsgroup or whatever using a company email account, or even identifying myself as an employee, even adding a disclaimer "not speaking for my employer" didn't cut it when I'd already identified myself as an employee. Like most legal issues, you never really know until there's some precedent, and some companies are more risk averse than others. I used to identify my employer on my blog, but I never do anymore; I've actually gotten to the point where I really have to think about posting anything work related. I'd rather have full disclosure, but I'm simply not permitted to by company policy. One special concern that a public company has is about stock price manipulation, there's a lot of things that you could say that are honest but could be viewed as market manipulation; for instance, talking about real problems with a product could be seen as making disparaging remarks about a product; if that product was visible enough, it could be seen as trying to depress the stock price.

— Gordon Weakliem at permanent link

Where Does All the Evil Come From, Anyway?

There's been a bunch of discussion on whether or not DataSets are really the root of all evil, starting somewhere around Scott Hanselman and summed up by Jon Udell. I suppose that's true if your definition of evil is "Interop", my immediate bias is that DataSets come with an interop problem; to wit: what the heck do I do with the urn:schemas- microsoft-com:xml-msdata and urn:schemas-microsoft-com:xml-diffgram-v1 namespaces? In general, I agree with Dare's assessment

...claiming that there is some philosophical reason not to expose data from an XML Web Service that may be be semi-structured and full of unknown data (i.e XML data) seems quite antithetical to the entire point of XML Web Services and the Service Oriented Architecture fad.

However, I don't think that you can realistically expect a client to deal with unknown namespaces, unless the client can realistically be expected to ignore them with no adverse effects. I'm all in favor of treating SOAP messages as raw XML (I'd rather that than do XML-Object Mapping, which makes me an oddball), but I have to be able to make sense of it. I'm not asking for the Semantic Web, just a few docs.

In the comments to Scott's post, Andres Aguiar pointed at Matt Powell's MSDN article, which actually is a nice discussion of the options and tradeoffs. This led me to do a little investigation, and it turns out that things have changed a bit since I last looked at this, in that I can't seem to coerce .NET to use DiffGrams. Which is interesting, has DataSet serialization changed in 1.1? From the looks of it currently, it looks to be the case, and though I really don't have any more time to look at it now, I might consider using a DataSet in a future service - if I could be assured of interop. Currently, it seems much more straightforward than in the past. Matt solves the easier problem: how do I pass a DataSet back from an ASMX? Clearly, you can just return a DataSet, but he simply implements a method that returns a DataSet, and doesn't deal with Update, which would require tackling DiffGrams. For Interop, Matt relies on exposing a second method, returning XmlDataDocument, exposing it as a serialized C# class. So I coded up his example, using my own data source, then running XSD.EXE to generate a class that I could serialize to. It was pretty painless, but not as straightforward as simply passing a DataSet. Which brings me to the next point: Barry Gervin mentions using DataSet to boost development speed:

We've been running a developer contest...developers build a solution build on a services oriented architecture which includes smart client, web services, enterprise services/com+ and of course data access. It's only a 1 day event, but the teams are built up of 5-6 people each. Inevitably, if one team decides to use datasets/dataadapters and the other team doesn't, the team that choose the dataset wins. This competition isn't judged or skewed for datasets by any means. But inevitably this is the thing that gives the other team more time to work on the interesting pieces of the application (like business logic: features and functions).

I'm a little split on this. On the one hand, it's a question of who's time you're saving, you might crank out a service quickly and then end up burning a lot of time helping your client with the interop issues. On the other hand, DataSets are useful precisely because they're antithetical to many of the principles behind the CLR; they're dynamically typed. A typed DataSet lets you get Intellisense back, but really doesn't change much fundamentally. A lot of the angst that I see from many of the participants in the debate is that they're running up against that fundamental difference in underlying principles. Barry recognizes the benefit of the dynamic nature of DataSet, but he wants to write code in a strongly typed environment. And I'll stop there before I get too predictable.

— Gordon Weakliem at permanent link