>> My advice to Oleg, if you want to see XSLT 2.0 in the .NET Framework then gather some like minded souls and build it yourself

You have *got* to be kidding me :) Since then is Microsoft behaving just like an Open Source community ("if you want feature XX just go build it")? What was the point of the .NET BCL (Base Class Library) if not to give developers a strong base on which they build their solutions? And isn't a (soon to be official) a W3C standard of widely used technology (XSLT) that Microsoft supports in version 1 (and even goes as far as giving us great debugger in VS2005) a reason good enough?

Btw, there is no need for Oleg to build anything. Altova, a small ISV from Austria has a conformant implementation NOW. Admittedly, it's all they do - provide XML related tools - but they had it for quite some time and their current implementation is conformant with the latest recommendation candidate.

>> A handful of XML geeks who want to see the latest and greatest XML specs implemented by Microsoft does not a business case make.

True, a bunch of devs ranting on blogs (yes, this includes me) do not make a business case. But that's not the point - we're talking about XSLT 2.0 and XPath 2.0 specs here. Both are second revision of widely used technologies on all platforms. Does it really take another ISV to build XSLT 2 and THEN Microsoft will EVALUATE if there are enough people out there needing this and MAYBE build it?

I really see no point in this post, except giving more ammo for Microsoft haters and bashers who will link to this post and basically say "you see, we told you that Microsoft is short sighted and non-agile and a copycat and"...

C'mon, you guys know better than that.

P.S. Yes, I am aware that this is your personal opinion and not Microsoft's official stance. If this is the way you'd handle it, I'm glad you're not in the XML team any more.

Drazen,
It seems you've misunderstood my post. The bottom line is that some geeks ranting in their blogs isn't going to make Microsoft implement a technology.

Secondly, you seem to be under the misapprehension that simply because a spec exists, it means Microsoft is obligated to implement it. This is far from the truth and ignores reality. No vendor implements every spec related to their problem space under the soon. There is an opportunity cost for implementing every spec and for Microsoft to commit to a technology, it has to be proved that this is the right choice for an important segment of its customers. How you prove this isn't likely to be by showing Microsoft's decision makers informal surveys in your blog.

My personal opinion is that instead of wasting your time trying to "prove" to Microsoft that there is demand for XSLT 2.0 [especially when they should know more about their customers than some random blogger] that instead if you have the ability, you should just provide the solution yourself.

>> Secondly, you seem to be under the misapprehension that simply because a spec exists, it means Microsoft is obligated to implement it.

Not at all. W3C has a lot of working groups that produce specifications all the time. Has Microsoft implemented all or majority of them? Of course not, and should not IMHO. Only technologies that are proven to be useful.

Now, isn't XSLT proven technology? I am sure you personally have used it too. Haven't you noticed that despite undeniable usability XSLT 1 has some flaws too? Doesn't it seem to you that XSLT 2 is solving most if not all of these? (for somewhat detailed list, please have a look at Kurt Cagle's blog entry linked to from Oleg's post).

>> How you prove this isn't likely to be by showing Microsoft's decision makers informal surveys in your blog.

Again, I agree. That was not the point of my response. It looks to me like you're dismissing the request to implement XSLT 2 because it's yet another W3C spec, and I argue that it is not.
Apparently, Oleg comes from the position of someone who's been told that if he wants to see Microsoft implement XSLT 2 , he should come up with a valid business case scenario. You seem to repeat this message too. So Oleg went out and asked if people find XSLT 2 important enough and why.

>> [especially when they should know more about their customers than some random blogger]

Exactly why then does Oleg need to provide this business case to Microsoft? Does he? Assuming that my analysis is correct, XSLT 1 being widely used and Microsoft supporting it, XSLT 2 should be a no-brainer: implement as soon as spec is final?

Btw, he is not just some random blogger. As you've noticed yourself, he is one of the authors of Mvp.Xml and if anything his efforts only help Microsoft and make .NET platform more popular.

OTOH, if you're just arguing the MEANS by which a particular blogger tried to get some attention and "influence" Microsoft to implement a particular technology, I'm cool with that.

>> I guess because I work at Microsoft, my perspective of 'valid business case' is different from yours.

Again and again - no it doesn't. *I agree* that bunch of geeks are not valid business case. It wasn't my point. My point was and is that XSLT 2 *is important* regardless and should not be taken lightly due to other reasons. It doesn't make it less (or more!) important if few of us publicly "vote" for Micrososft to implement it on our blogs.

>> What constitutes a valid business case for Microsoft to make such an investment would be either (i) some large customer or many small customers saying they decided to switch from our platform because of lack of XSLT 2.0 support or (ii) some large customer or LOTS of small customers who will move to our platform because XSLT 2.0 exists.

Yes, but in reality you can see that not all features are implemented until one of the two criteria you mention are met. Let me give you an example - I was using Microsoft's XSLT processor while it was still in beta (early 2000). At that time, XSLT 1.0 spec was VERY fresh and there's no way Microsoft waited for the widespread adoption until a decision was made to support XSLT1. OK, old example, here's newer.
Microsoft has actually already invested in XPath 2.0 through attempted support of XQuery 1.0. Due to spec not being final, the support was withdrawn until final recommendation is issued. I completely agree with this approach - I still remember the trouble I went through struggling with the non-conformant XSD implementation (XDR) at the time. So, XQuery is out, no? It isn't - it's subset that *Microsoft thinks won't change* is present in the SQL Server 2005.

Don't tell me that "some large customer or many small customers saying they decided to switch from our platform because of lack of XQuery 1.0 support" in SQL Server 2005???

We basically agree that lobbying on the weblog will not influence Microsoft enough, in the sense that it provides a valid business case. We disagree whether in this particular case it actually matters...

I think,Drazen was talking about xslt1 design flaws and xslt2 can solve most if not all issues with it.I completly agree with him,xslt2 should be seen as bug fix release of xslt1 and from that point of view have more priority even than XQuery in SQL server.Anyway,xslt2 is the same templating engine we like but conceptually properly implemented.

Regards.

Dare,

I'm in the midst right now of writing a chapter on XSLT 1 as part of a book on XML in Firefox, and should honestly not be taking the time to write this, but given that I seem to be, along with Oleg Tkachenko, Dmitre Novatchev and M. David Peterson, one of those "geeks ranting on blogs" and a "random blogger", I felt it rather incumbant to say something.

I am my company's representative to the W3C SVG and CDF working groups, have written at least five books and more articles than even I can remember about XSLT technologies, and have worked very diligently to push and promote XSLT technologies since its inception.

Oleg is a Microsoft MVP and has a long track record of pushing and promoting what he feels are important technologies, some within the framework of the W3C, others that he feels supports Microsoft in its mission.

Dmitre was, along with Jenni Tennison, Michael Kay (the editor of the XSLT 2.0 spec and by many considered the authority on XSLT), Daniel Veillard (the primary developer of the libXML2 engine that underlies almost all XML technology in Linux) and myself, instrumental in pushing EXSLT.org and laying much of the ground work for the XSLT 2.0 specification.

M. David Peterson has likewise worked with Microsoft for a number of years and has gained a solid reputation for evangelism and understanding of a wide array of XML technologies.

In short, these "random bloggers" probably have more experience than anyone else on the planet with XSLT technologies, and all of us are pretty uniform in our feeling that XSLT 2.0 is a necessary, perhaps even critical update to the XSLT 1 specification that fixes many of its inherent problems while reducing the code development size by a factor of 10. It is not meant to replace or compete with other Microsoft technologies - I've long regarded the MSXML and MSXML.Net components to be best of breeds in their respective classes, and they nicely complement other Microsoft technologies, but rather XSLT2.0 will make Microsoft's tools far more palatable to a fairly large proportion of customers who see that component as integral to their needs but is not available within the .NET framework.

I get frustrated when I see attitudes such as yours, as I feel that such attitudes represent the worst of Microsoft, a belief that simply because a technology did not originate in the hallowed halls of Redmond (and yes, I too have worked in those halls) that it is beneath contempt. There is a double standard that says that it is perfectly all right to push yet another XML standard (XAML) on customers who may or may not have a compelling business case for its use, but that the upgrade of a standard which MICROSOFT ITSELF supports extensively requires affidavits from every single Fortune 500 company just to get one developer spending a week workig on it.

I don't few people are going to fault Microsoft for not supporting SPARQL or XForms - though I suspect that the company will have no choice but to support SVG once it gets into every other browser or risk falling further behind, but XSLT 2 is different. In publishing, media processing, work flow management, orchestration, application development, web development, and many other areas XSLT2 could significantly reduce the amount of coding while simultaneously improving the maintainability of that code.

Overall, XSLT2 adoption has been slowed only because of a concerted effort to integrate XPath (which was dependent upon XQuery, a techology that Microsoft pushed heavily then backed away from). It's publication will take place within the next two to three months. Already, every day, people are downloading Saxon 8 or Altova's XSLT 2 release, and are building solutions with Tomcat or via LAMP stacks, and are consequently moving farther and farther away from a dependency upon Windows technologies.

When the specification is released next February, many other companies will be developing their own processors, and it is likely that most of those will not be on .NET. Why? Because there will be the expectation on the part of Microsoft's customers that they want to use the Microsoft version of a technology that core rather than writing their own. In my experience as well, XSLT, as with the case of XML in general, tends to be a pervasive technology ... once introduced into a system, the system tends to reorient around an XML/XSLT paradigm.

This means that those customers that you so demand declare their allegience to this or that standard or format before you'll even begin to consider building it will likely decide the issue in favor of XSLT2 once they see how the wind breaks. If Microsoft DOESN'T have an XSLT2 solution, then those customers will go elsewhere ... it's that simple.

Thus, this "random blogger" would recommend that you spend some time actually looking at this technology that you seem to be so insistent is a bad thing, go out and actually talk with those real world customers, explain what XSLT2 CAN do, and THEN do your metrics and analysis. I suspect you'll find that there are far more customers out there who once they know how to work with the technologes,

Sincerenly,

Kurt Cagle

Kurt,
>I get frustrated when I see attitudes such as yours, as I feel that such attitudes represent the worst of Microsoft, a belief that simply because a technology did not originate in the hallowed halls of Redmond (and yes, I too have worked in those halls) that it is beneath contempt. There is a double standard that says that it is perfectly all right to push yet another XML standard (XAML) on customers who may or may not have a compelling business case for its use, but that the upgrade of a standard which MICROSOFT ITSELF supports extensively requires affidavits from every single Fortune 500 company just to get one developer spending a week workig on it.

*sigh*

I don't work on the XML team anymore. Perhaps this 'attitude' you are blaming on me is one of those reasons.

If Microsoft is going to implement XSLT 2.0 in the next version of the .NET Framework or not, it isn't going to be because (i) the spec is complete or (ii) XSLT experts demand it. This may offend your sensibilities but it is the cold, hard reality.

Now you can adjust to this reality and figure out your alternatives or you can decide to blame me someone who doesn't even work on the XML team anymore. I know which one I'd consider a more productive use of my time.

PS: There is a business case for XAML. Just ask any developer who's used Winforms.

Dare, I'm not making a business case of course. I'm just asking people reading my blog for such information, because I've been asked for help. Take a look into XML MVP private newsgroup for the root of this noise.
Thanks for the plug anyway :)

Dare,

=snip=
If Microsoft is going to implement XSLT 2.0 in the next version of the .NET Framework or not, it isn't going to be because (i) the spec is complete or (ii) XSLT experts demand it. This may offend your sensibilities but it is the cold, hard reality.
=end snip=

Read my post again, rather than what you want to see in my post. I never make either claim - indeed, I believe, reading it over again, that I make precisely the oppositve claim. There ARE compelling BUSINESS reasons for adopting XSLT2, reasons which I've tried to hammer out repeatedly to very interested audiences.

If you agree to the argument that XSLT1 has strong utility in today's marketplace (and given the number of XSLT implementations currently in use I think its a safe bet) then XSLT2 gives you considerably more power, more consistent integration and extensibility mechanisms, dramatically reduced code size and complexity, fixes many of the glaring holes that have been known of XSLT1 since its inception, and in general provides you with a more powerful engine and better code.

If you can get away with hiring considerably fewer XSLT2 developers in an organization, then those are REAL cost savings.

If you can reduce your debugging and maintenance times because you need 1/5 the code, that's a REAL cost savings.

If you put extension developments in the hands of .NET or Java or Javascript or anyone else as appropriate to the environment, then that cuts down on the number of "XML Developer Specialist" that you need working with complex and arcane syntaxes, and THAT is a real cost savings.

If you can integrate data integration (XQuery) with transformation (XSLT2), then you reduce the dependencies upon complex "bridge" pieces, which not only saves you development costs but it increases your performance as well.

Once the business case is made, most vendors are far more anxious to know WHEN they can get it rather than wondering if its worth taking the time to investigate it.

I DO know members of the XML team at Microsoft, and I think that by and large they are weighing XSLT2 very carefully right now, precisely because their customers are coming to them and asking when it will be integrated into the offerings. I also know that you are not working with the XML Group, but that you are an influential voice there - when I see attacks on the technology not on the basis of the merits of the technology (something I have not yet seen from you) but rather taking the approach of deprecating the technology (and those who would defend it) because it does not seem to fit within Microsoft culture, I think it paints a very poor light both upon you and upon the culture that you are trying to promote.

Getting past the invectives, I ask you a simple question:

What is it about XSLT2 that you see makes it a technology not worth Microsoft investing in?

I've been one of many voices that have argued the pros of the technology. You apparently seem to feel (if I read you right) that it is not a technology that you, as an authority if not necessarily one in a position of making a decision, feel is appropriate for Microsoft to be pushing? If you can make the business case against it, I, and a lot of other people, would like to know what it is.

-- Kurt

P.S.: I do not work for a competitor of Microsoft (for the record, I work for Mercurial Communications, which is a consulting company that does both .NET and Open Source development). I am advocating the technology because I think it solves most of the problems that XSLT 1.0 has while staying consistent to it, and because there are times that technologies that don't have billion dollar budgets need to be evangelized because they are simply good ideas.

P.P.S.: When I went to post this message, I received a web diagnostics page saying that I had "dangerous code" in my message, it seems because I included the words snip and /snip encased in angle brackets. If this is what WinForms has to offer, then sign me up for Ruby on Rails.

One short comment on this storm in the waterglass re XDR: XML Data Reduced (XDR) was not a non-conformant XSD implementation, it was a precursor of XSD that we designed and that was forming some (somewhat ignored) input to the standardization process....

>> XML Data Reduced (XDR) was not a non-conformant XSD implementation, it was a precursor of XSD that we designed and that was forming some (somewhat ignored) input to the standardization process....

You are right, bad choice of words on my part. If you read between the lines, you might get my point - Microsoft implemented XSD early, before it reached the status "recommended". Make no mistake, I NEEDED that at the time and I used it. But later on it proved to be more trouble than it was worth it, so now when Microsoft says "let's wait till the spec is final" I nod approvingly :)