venerdì 20 novembre 2009 20:52Now that .NET 4 is coming out, is there any plans to bring the .NET XSLT processor up to date?
.NET's XSLT engine used to be an industry leader offering very fast performance, but the fact that Microsoft has not kept it up to date (the MS transformation engine cannot handle XSLT 2.0/XPath 2.0) has caused a number of problems.
I'll use Saxon if I have to, but I'd truly love to use the .NET performance tools with up to date XSLT.
- Tipo modificato Allen ZhangMicrosoft Employee, Moderator sabato 11 settembre 2010 02:07
Tutte le risposte
sabato 21 novembre 2009 12:05.NET 4/Visual Studio 2010 is out in a public beta 2 version. The only XSLT specific change I am aware of is that xsltc allows signing, as announced here http://social.msdn.microsoft.com/Forums/en-US/xmlandnetfx/thread/88f3a46c-2c80-4101-9923-54a0d9792fad
If you want XSLT and/or XPath 2.0 you will need to use third party solutions (but you don't have to wait for .NET 4.0). You are already aware of Saxon, there is also AltovaXML tools providing XSLT 2.0 and XQuery 1.0 via COM interop, and for XPath 2.0 and XQuery 1.0 there is also XQSharp .
MVP XML My blog
sabato 21 novembre 2009 21:54
Why has Microsoft allowed it's investment in XSLT to whither?
Is it because they are trying to encourage the use of proprietary technologies such as Linq and F#?
From what I saw at DevConnections, Microsoft is investing in XML more and more. It just makes sense to me that they'd be interested in maximizing that investment by making use of XSLT/XPath - the best technology in the industry for transforming XML.
I'm not trying to be snide here, I'm just trying to understand the rationale. The reality is, Microsoft still has a hegemony over the industry and, while that hegemony is coming under greater and greater attack from companies like Apple and Google, Microsoft still has a great deal of control over which way the wind is blowing. If I could get in their heads and figure out what they are thinking and why - if they'd have a dialogue with the people who use .NET and explain what they are doing - it'd help me as a developer.
I guess what I'm looking for is a reason to be a little less disenchanted with .NET. I'm far too often running into things .NET doesn't allow - whether it is using the full 64bit capability in an application which connects to MS Access or creating an XML Pipeline or creating a secure software application which actually disposes of vulnerable data in a reliable and safe manner when you tell it to or any of a number of other things, I usually discover that .NET can't do it. It seems like, unless a developer's software design fits within a very narrow design horizon, it's better just to use something besides .NET and, well, it's frustrating. Especially since the reason this seems to happen more often than not is that Microsoft ignores industry standards (such as XSLT) and keeps trying to reinvent the wheel (such as with Linq) and, when they reinvent the wheel, they have to start over from scratch so they never get as far as if they embraced industry standards (and, hence, made use of the lessons learned therefrom).
I find irrationality frustrating. If Microsoft would give a sensible explanation for what it's thinking, it would help a great deal. Because I can handle differences of opinion. What I have trouble dealing with is things which just don't make sense.
sabato 21 novembre 2009 23:39I think that it is not true that Microsoft has given up on advancing XML technologies. Case in point: the next Visual Studio IDE will include a completely new and comprehensive XML schema editor. This is not something someone would do if they wanted to stop investing in XML standards! On the other hand, XML programmability enhancements are clearly not a major component of the .NET 4.0 release. I for one would like to see better support for XML schema-object mapping (that is, a new iteration of the XmlSerializer kind of technology). Sure there are frustrations. We all want everything right now, but sometimes patience is in order.
I wouldn't underestimate LINQ, including LINQ to XML (XDocument). It doesn't sound like you have used it much, but it is generally much better than XmlDocument. Also nice is its XML integration with VB (if you happen to be using that language), a feature that I'd love to see brought into C# as well.
> they have to start over from scratch so they never get as far as if they embraced industry standards
These standards are often the results of design-by-committee with lots of compromises and inconsistencies that do not make sense technically. Sadly, they often show what not to do. For example, see the XML Schema specification. But yes I will agree that it is nonetheless important to keep up with the standards while at the same time advancing elegant features like LINQ.
domenica 22 novembre 2009 00:52If Microsoft were to follow the design path set by these design-by-committee open standards, rather than go along a completely different path, they could build upon the successes and failures of those design-by-committee open standards and achieve more functionality with them than could be done by starting from zero all over again.
That's my point.
In many cases, Microsoft has learned its lesson. Developers now have an alternative to .NET Web forms (.NET MVC - have you ever noticed that .NET MVC looks a lot more like classic ASP then Web forms do?) and SOAP (.NET is implementing REST more and more - ie. the way the web is suppossed to work) - of course, they are playing catch up because they sunk so many resources into trying to reinvent the wheel. And, yet, they keep trying to reinvent the wheel. How's that old joke go? "Doctor, doctor, it hurts when I do this!" "Well, don't do that!"
martedì 7 settembre 2010 10:37
We have have just released a beta version of XQSharp 2.0.
XQSharp is an implementation of XSLT 2.0 (new in this version), XQuery and XPath 2.0 for the .NET Framework. It is free for non-commercial use. Visit http://www.xqsharp.com/ for more information.
We are not quite as fast as the XSLT 1.0 implementation built into .NET, but we are however at least as fast as any other XSLT 2.0 implementation available for .NET. We are working on compiling to MSIL byte code, and when this is finished we hope to have performance comparable with the built in XSLT 1.0.
mercoledì 8 settembre 2010 23:54
Xslt 2.0 /XPath 2.0 is not a part of .NET 4.0.
This posting is provided "AS IS" with no warranties, and confers no rights.
- Proposto come risposta zoyab- MSFT mercoledì 8 settembre 2010 23:54
giovedì 9 settembre 2010 02:58Moderatore
Thank you very much for your question. Unfortunately, as you are aware that XSLT 2.0 and XPath 2.0 support are not in .NET 4.0.
We are actively looking at the bring our XML technology stack(s) upto the current standards/editions, XSLT 2.0 and XPath 2.0 being on top of the list. We will communicate it out to the developer community once the roadmap is finalized.
Once again, thank you very much for your suggestions and participations in our forum!
- Contrassegnato come risposta Allen ZhangMicrosoft Employee, Moderator giovedì 9 settembre 2010 03:00
martedì 18 gennaio 2011 20:21Any update if/when Microsoft is going to implement this?
venerdì 8 aprile 2011 18:58While it seems like it's beating a 3+ year old dead horse I would like to chime in on my interest in if/when/what plants for Xslt 2.0 Microsoft has.
martedì 1 novembre 2011 12:35Any news on Microsoft's XML technology stack?
- Modificato asdfasfsdfsdf martedì 1 novembre 2011 12:37
giovedì 2 febbraio 2012 21:54MSFT - I am also looking to beat the dead (but hopefully not rotting) horse... anything planned for .NET4.5/5.0's support for XSLT 2.0 to bring her back to life? TIA.
mercoledì 22 febbraio 2012 18:46
I am also looking for an update on .NET 4.0 plus using XPath 2.0. Why? I want to use schematron to validate basic business rules in .NET. and not be limited to number comparisons.
All I want to do is compare Dates and DateTimes and not have to convert it to a number and use the > or < operators...
I guess I will have to use Saxon (another 3rd part tool) to do this.
lunedì 27 febbraio 2012 18:16
If you're using XPath in XSLT and are interested in needing extended functions you have a lot of options available to you. http://msdn.microsoft.com/en-us/magazine/cc302079.aspx shortened version of the article specific to C# and XSLT http://our.umbraco.org/wiki/reference/xslt/extend-your-xslt-with-custom-functions
You don't necessarily need to use XSLT files either. If you wish to extend XPath with functions you can use similar functionality to create advanced xpath functions and utilize it in your xpath queries.
Again, not the most ideal solution if what you're doing is something that could be doine by the latest XPath implementations (if it were implemented) but it might be less costlier than switching to a 3rd party tool/library that may or may not be free but may require lots of effort to integrate.
Still however, it really would behoove Microsoft to implement the latest standards for XSLT and Xpath - especially since XDocument ended up being so horrible from a developer perspective (imho) and virtually unusable and definitely extremely pain filled and not very extensible or intuitive.
lunedì 27 febbraio 2012 18:58
Thanks for the reply.
I believe the solution from http://our.umbraco.org/wiki/reference/xslt/extend-your-xslt-with-custom-functions umbraco require an installation of some 3rd party package also. If true, how does that compare to using a 3rd party install like Saxon? Is Umbraco easier to implement?
- Modificato d_vm23 lunedì 27 febbraio 2012 18:58
martedì 28 febbraio 2012 03:56
As far as I am aware it does not. If you read the first MSDN link I provided you will see that the code Umbraco shows that references no UMBRACo components mimics 2 code snippets that are used in the MSDN link. From my understanding they are merely showing you a MS technology that you can leverage while extending UMBRACO.
Additionally as I said in my prior statement, if you're not using XSLT and just want XPATH the 3rd link (CodeProject) that i provided is probably more relevant.
This was the XSLT Extensible link I was actually originally looking for. http://www.pedautreppe.com/post/Calling-C-function-in-XSL.aspx
I think this method mirrors one of the ways provided in the first 2 links, it just is a bit more cleaner (imho) (if you're going the XSLT route).
giovedì 1 marzo 2012 23:18
I would like to see XSLT 2.0 as well, or at least the ability to output XHTML with XSLT 1.0.
Internet Explorer appears to support 2.0 and <xsl:output method="xhtml"
Why not VS/.NET?