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
.NET in several flavors there's a chance that we can help save XSLT from
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
.NET. Come Monday I hope I am able to give a decent progress report 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(_at_)colina(_dot_)demon(_dot_)co(_dot_)uk]
Sent: Thursday, May 13, 2004 10:27 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] killing xslt
"David" == M David Peterson <m(_dot_)david(_at_)mdptws(_dot_)com>
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
--+------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--+--