[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: killing xslt
Looks like I mixed 2 thoughts into one in this last post. This section: " If we all jump in and support the effort to get XSLT 2.0 up and running on getting completely dogged in the media..." Should read more like: "If we all jump in and support the effort to get XSLT 2.0 up and running on .NET as quickly as possible maybe we can avoid XSLT's future as a development tool getting completely dogged in the media and as such avoid having to perform any type of resuscitation in the coming months by jumping out of the gate with a "doesn't matter, we've already developed XSLT 2.0 support and here it is" message to deliver to the decision makers who are driving the development efforts of our future." Sorry 'bout that! I started one thought process and then added to that process a bit later. Looks like I didn't properly conjoin the edits :) Hope the above now makes more sense :) <M:D/> > -----Original Message----- > From: M. David Peterson [mailto:m.david@xxxxxxxxxx] > Sent: Friday, May 14, 2004 1:40 AM > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: RE: killing xslt > > FanFREAKINtastic! Do you have a sense for when the port will be > completed and is there anything I can do to help? If nothing else would > love to QA this for you as Im sure there are many here who would love to > do the same :) > > Thanks for the information! I myself plan to do a simple run of the > Saxon 7.9.x code through the MS Java to C# conversion utility and see > where we end up. If it goes well this would be an ideal situation for > MS to highlight their conversion tool as something that does a swell job > of creating a platform to platform conversion of Java "with only X% of > hand massaging the code to get from one "executable" to the other." If > we all jump in and support the effort to get XSLT 2.0 up and running on > getting completely dogged in the media and as such avoid having to > perform any type of resuscitation in the coming months by jumping out of > the gate with a "doesn't matter, we've already developed XSLT 2.0 > support and here it is" message to deliver to the decision makers who > are driving the development efforts of our future. Nobody from MS has > dared yet to say that they chose XQuery because they feel it is a > superior technology to XSLT but instead because of a combination of > reasons (all dependent on how you translate Mark Fussell's original blog > (http://weblogs.asp.net/mfussell/archive/2004/05/13/130969.aspx) and the > follow up from Dare Obasanjo's "clarification" post > (http://blogs.msdn.com/dareobasanjo/archive/2004/05/13/131166.aspx)) > that stem from there desire to evangelize and convert a larger base of > potential developers who "prefer" the SQL-like syntax of SQL over the > XML-based syntax of XSLT. That leaves a golden opportunity for all of > us who have taken the time to learn and as such embrace XSLT and it's > functional-based nature to stand up and say that we will take on the > continued development and support of XSLT for version 2.0 and beyond. > In Mark Fussell's post he mentioned a 5 year "window" in which they will > know if they made the right decision. Sounds like just the right time > frame for MS to be able to jump back into things for what could > potentially be the release of XSLT 3.0 if they find that the decision > they made did more harm than good. But in the mean time the support > will be on all of our collective shoulders. I know I am definitely down > for the challenge! :D > > I've just read arpande's post "PROMISES, PROMISES" > (http://blogs.msdn.com/arpande/archive/2004/05/13/131408.aspx) which is > a follow up to the post's from above. Although I still believe there > decision to be wrong it does give a more logical breakdown of why they > made the decision that they did (giving a TON of credibility and > foundational support to Michael Kay's "suggestion" that this all stems > from funding issues and the fact that XQuery's SQL-like syntax has > generated more internal funding because of the simple fact that SQL > Server and other SQL-based tools and products make money where as XSLT > has no product base to dip into for support) and how they have continued > to push the existing XSLT/XPath 1.0 implementations into the "Whidbey" > product and as such are not killing XSLT so much as deciding that the > current XSLT/XPath releases provide enough functionality to drive the > areas in which XQuery lack's capability or where other products provide > the necessary support to the additional functionality made available in > XSLT/XPath 2.0 - simply stated as template-based matching > transformations. The part of the post I find most interesting - and had > at one point in my post to Mark Fussell's blog written about 1/2 a > paragraph on before deciding not to take the post to far away from the > XSLT core and as such deleted it - was conclusion 3 stemming from the > content of paragraph 4: > > "ASP.NET 2.0 is a phenomenal product. Many of us believe that one of > our key XSLT scenarios, HTML generation, will be greatly diminished with > the ease in which an ASP.NET solution can be developed. There will > still be cases for XSLT on a web server, however this will be reduced in > time." > > I think we can finally say that we have found the core reason behind the > decision to drop support for XSLT 2.0 - It competes with ASP and has > been doing so since day one. I was working on the Redmond campus when > XSLT first appeared on the scene and at the time found it curious that > MS was even considering support given the fact that it was in many ways > a direct competitor to ASP in the area of dynamic generation of HTML. > In fact it was for this very reason (as well as an email that was sent > out during the same time frame from an MS-Exec - wouldn't be proper (as > well as contractually legal) to say who - to all the developers at MS > describing the changes on the horizon that were being driven by XML and > that if we wanted to be marketable commodities in the years to come that > we had better do all we can to learn as much as we can about XML and all > of its related technologies) that I decided to invest my time into > learning XSLT/XPath as well as Web Services and other XML-based > technologies. My thought at the time was that if MS felt this strongly > about these technologies that they were willing to add support for them > directly into products that were in many ways there direct competitors > then I had better pay attention. And I'm glad I did. Although my > dynamic web development experience began with MS and ASP in '96 and has > been the foundation of most of my dynamic web development ever since > XSLT won my heart over many years ago for its ability to transform XML > in a way that no other technology can even come close. I guess we shall > see just what arpande means when we are given access to the ASP.NET 2.0 > bits. None-the-less I have every plan and intention to do all I can to > see XSLT 2.0 support made available to the .NET platform. > > I have to fly to Denver for the day tomorrow but my weekend has been > dog-eared to jump into the Java-to-C# conversion of Saxon to be run on > just where we're at with getting the port to C# up and running. I am > REALLY looking forward to taking a look at your Eiffel-based port of > Saxon 7.9.x! Again, let me know if I can in any way be of assistance to > you. > > Best regards, > > <M:D/> > > > -----Original Message----- > > From: Colin Paul Adams [mailto:colin@xxxxxxxxxxxxxxxxxx] > > Sent: Thursday, May 13, 2004 10:27 PM > > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > > Subject: Re: killing xslt > > > > >>>>> "David" == M David Peterson <m.david@xxxxxxxxxx> writes: > > > > David> There is too much opportunity here for me to believe that > > David> someone hasn't already begun either a port of Saxon or a > > David> brand new engine that will support the 2.0 standard on > > David> .NET. > > > > I'm (unintentionally) porting Saxon to .NET. > > That is, I'm translating it into Eiffel for use within (and without) > > Gobo (http://www.gobosoft.com) - the open-source portable Eiffel > library. > > Since Gobo support for Eiffel compilers includes ESI Envision product > > (which compiles Eiffel code to the .NET platform), this means it will > > be runnable on .NET. > > -- > > Colin Paul Adams > > Preston Lancashire
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|