RE: [xsl] killing xslt

["M. David Peterson" <m.david@xxxxxxxxxx>]

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: [xsl] 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: [xsl] 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