Evaluating XML Value

Evaluating XML Value

  • Comments 2

There has been a bunch of discussion in the community (with commentary) on XSLT 2.0 and whether Microsoft should impement the recommendation (as well as how & when).  I started tracking the external discussion by reading DonXML's thoughts as well as Dare's point of view and it blossomed from there.  With all this talk about business cases it got me thinking about how we evaluate value and how the community can have the maximum impact on that evaluation.  The point of my post isn't about XSLT 2.0 - it's about the decision making process here at Microsoft and how we can all learn to work better to get the right things done.  However since XSLT 2.0 seems to be a hot topic (or was last week) I figured I'd use it as an example.

Assertion: Personally I want the team to implement XSLT 2.0 more than anything if it is the best use of our resources to create additional Value for the existing and prospective XML development community.

Question: How do I assess that?  With many exciting projects like XLinq, improving our XML tools experience, XSLT 2.0, and every other idea / request that lands on our table + supporting millions of existing MSXML and System.Xml customers (some or even many of whom will never utilize any of those new features) how do we decide where to invest with finite resources?  And remember it's not just the implementation cost - it's a long term support contract too...

So what's a person who's taking input to prioritize supposed to do?  Well, the current formula I think we use around here comes in two parts:

- W3C Status + High Level Metrics (e.g. total XSLT adoption) + Competitive Pressure = External Forces
- External Forces + Customer Scenarios + Intuition = Value

When we perceive Value is greater than Total Cost of Ownership...including that long-term support deal we will consider an implementation... (of course, there's always opportunity cost to factor in, but that makes my equation too complicated).  When Business Case Value < Total Cost we put it on the back burner...at least for awhile and then re-evaluate later.

So now the question becomes, "how can the community have maximum impact on the equation?"  It would be great if we could just ask you guys to assign an overall Value (or a really high Intuition value) - it would make our jobs a lot easier, but then you would be us, and that would be really confusing.  External Forces aren't usually good candidates to influence either - you could clue us in on a new competitor or share some experience of a *specific* customer moving say from our platform to another platform to use a particular XML feature but things like market share and usage patterns are usually quantitative data and it's hard to gather enough (especially from a non-random sample of people) to be statistically significant and affect the overall Value calculation.

So I think the biggest area of impact is Customer Scenarios... it gives us context and I think has a "network effect" of driving our Intuition positively as well.  So what do I mean by Customer Scenarios?  I think too often people confuse Features with Customer Scenarios.  A Customer Scenario to me is a little slice in the life of a developer that other developers immediately grab on to and understand.  One that has seemed to stick with me was when I was talking to Jeff Julian about using XmlReader as a method parameter on public APIs - He says something like, "It drives me crazy when I want to pass around an XmlReader to other layers in the system because there's no way for me to guarantee that other people's code doesn't read too far and leave my reader state all messed up. I wish I could set regions on the XmlReader."  He didn't have to say much but I understood the issue much more deeply from his Customer Scenario than if he had said - "the XmlReader needs regions (or subtrees)" (a Feature).  And now I can apply that scenario, which seems pretty common (a little Intuition), to all the developers who want to pass XmlReaders around the system - and Jeff is no longer Jeff, but he is a representation of everyone in the community who has that same problem.  (Sorry Jeff, I'll return your identity at the end of my post).

When I apply that to the XSLT 2.0 discussions that have been floating around the various blogs - I haven't seen a ton Customer Scenarios.  Kurt Cagle's "Business Case" is definitely a step in the right direction, but is still relatively technology-centric - although he does have some concrete examples which are great!  Just requesting a Feature is very unlikely, from a quantitative perspective to tip the scales.  It's just +1 dev that wants a Feature (even if these are some of the more expert XSLT devs in the world).  I think this is the point Dare was trying to make... but here's where he and I differ.

If you can hone in on the "WHY" of the Feature (and that is the Customer Scenario or Scenarios) suddenly you wield a mighty sword indeed.  Most people on this team get up in the morning because they like solving problems to help other developers. Help us see the reason behind your passion for the Feature.  The community can provide a breadth of perspective that we don't have here whether it is from your own coding, problems you've help your clients solve, or things you've seen elsewhere in the community - give us the WHY.  What's the problem that you're trying to solve from the perspective of the task at hand.  Grouping in XSLT 2.0 isn't interesting to implement because XSLT 1.0 doesn't have it - it's interesting because it addresses a real pain point that affects XSLT developers every day.  I had someone walk into my office the other day and ask how to create nested tables with XSLT 1.0 to display some data grouped by year and then month... 

Some of the more compelling XSLT 2.0 arguments I've seen have come from Oleg's blog comments.  Andrew Houghton gives a very concrete example of what he was trying to do, how he was blocked, and what XSLT 2.0 would do to solve his problem.  Just like with Jeff's example above, now Andrew isn't Andrew anymore, he's also all the other developers stymied by strict security requirements and lack of good support in XSLT 1.0 for uri-encoding and unicode normalization.

So when you are passionate about that feature / widget / API - tell us a story that fills in a little more context and let's us generalize from the issue you were facing to the community at large and leverage our Intuition. My guess is this will send Value calculations for that feature on an upslope.  As for the actual decision on XSLT 2.0... stay tuned.  We're still turning the crank over here but there has definitely been a groundswell of support.

Let me know what you think

Adam Wiener