Is there a reason for not using XSLT 2.0 as a default

[Daniel O'Donnell]

Hi,
I have a question that calls for informed opinion: is there a reason
for not using xslt 2.0 for most processing tasks? I'm thinking
especially privatish, and pre-processed things rather than on-the-fly
commercial applications.
The standard is now pretty stable, correct? and the processors seems to
be working well. Saxon 8b-3 is very good, and since Saxon 6.5.3 has a
bug that seems to stop it writing properly in Service pack two XP
machines, it may be a good time to switch anyway.
No doubt a trivial question, but I'd be interested in hearing what
people think. I'm engaged in a couple of new project involving xslt
where the question of 1.0 or 2.0 is real.
-dan
--
Daniel Paul O'Donnell, PhD
Associate Professor of English
University of Lethbridge
Lethbridge AB T1K 3M4
Tel. [phone]
Fax. [phone]
E-mail <***@uleth.ca>
Home Page <http://people.uleth.ca/~daniel.odonnell/>
The Digital Medievalist Project: <http://www.digitalmedievalist.org/>


--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Elliotte Harold]

I can see two issues. First, you'll tie yourself to a single vendor.
That's not much of an issue, since you would probably pick a single vendor
anyway and since Saxonica is a fine vendor. Second, the 2.0 specification
may change before it is finalized. However, that risk seems to be low, as
the working group is winding down (so I gather anyway).

I certainly wouldn't count on that. It is far from unheard of for a
working group to think it's winding down when someone comes out of left
field and identifies an unrecognized problem that causes a major rethink
and redesign. It doesn't happen to every or even most specs, but it does
happen often enough to be a problem. So far I've seen this happen to
XPointer, XInclude, SOAP, and xml:id. (There might be others I'm just
not thinking of right now.)

There are numerous other specs where this should have happened but
nobody noticed the problems until after final publication. XSLT 2 isn't
done until the final spec is released, and maybe not then.
--
Elliotte Rusty Harold ***@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[M. David Peterson]

Post by Elliotte Harold
(There might be others I'm just

not thinking of right now.)

In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propogated and
a support nightmare to be invoked. I would tend to think that the W3C
has made the necessary changes to ensure that this kind of thing
doesn't take place again but I would also consider the fact that, as
Mr. Harold recognizes, last second changes happen often enough that
the possibility must be considered when making any long term plans for
a technology.

With that said, it seems the latest release of the XPath 2.0, XSLT
2.0, and XQuery drafts have gone a long way into fixing a lot of the
areas that may have been considered questionable or potential problem
areas but caution still must be employed none-the-less.

Best regards,

<M:D/>


On Tue, 08 Mar 2005 14:03:25 -0500, Elliotte Harold

Post by Elliotte Harold

I can see two issues. First, you'll tie yourself to a single vendor.
That's not much of an issue, since you would probably pick a single vendor
anyway and since Saxonica is a fine vendor. Second, the 2.0 specification
may change before it is finalized. However, that risk seems to be low, as
the working group is winding down (so I gather anyway).

I certainly wouldn't count on that. It is far from unheard of for a
working group to think it's winding down when someone comes out of left
field and identifies an unrecognized problem that causes a major rethink
and redesign. It doesn't happen to every or even most specs, but it does
happen often enough to be a problem. So far I've seen this happen to
XPointer, XInclude, SOAP, and xml:id. (There might be others I'm just
not thinking of right now.)
There are numerous other specs where this should have happened but
nobody noticed the problems until after final publication. XSLT 2 isn't
done until the final spec is released, and maybe not then.
--
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
--~--

--
<M:D/>

:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[David Carlisle]

Post by M. David Peterson
In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propagated and
a support nightmare to be invoked.

I think that's a very skewed view of history:-)

The split between FO and XSLT into two specs wasn't that late in the
process : including the REC there were 7 drafts of XSL(T) only the first
two of which were combined with FO.

and was essentially irrelevant to the microsoft implementation
as it never implemented the FO part of the draft even when they were
combined, splitting it just made it easier for the transformation-only
implementations to claim conformance to a named spec rather than just to
chapter 2 of a combined spec.

msxml2 implemented a language that had a passing resemblance to the
transformation language in the XSL draft of December '98. Even if it had
been a faithful implementation of that draft, releasing an implementation
of a draft spec in a full non-beta release of a piece of software
distributed to 90% of the world's desktops was a mistake, although at
the time I think many of us thought it was probably a good thing,
spreading the word... It's easier to take a different view with hindsight.

Post by M. David Peterson
I would tend to think that the W3C has made the necessary changes to
ensure that this kind of thing doesn't take place again

I don't think the W3C process can have any effect on such
things. Companies (or people) will take commercial decisions on whether
to release (or use) software based on a draft spec. If they do release
such software again they will take commercial decisions about whether
to change the software as later drafts come out.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[M. David Peterson]

Thanks for this added info... Of course its easy to develop an opinion
in one direction or another based on the information you are aware of
so it certainly helps to understand things further from someone who
has watched this process from the beginning.

Cheers :)

<M:D/>

Post by David Carlisle

Post by M. David Peterson
In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propagated and
a support nightmare to be invoked.

I think that's a very skewed view of history:-)
The split between FO and XSLT into two specs wasn't that late in the
process : including the REC there were 7 drafts of XSL(T) only the first
two of which were combined with FO.
and was essentially irrelevant to the microsoft implementation
as it never implemented the FO part of the draft even when they were
combined, splitting it just made it easier for the transformation-only
implementations to claim conformance to a named spec rather than just to
chapter 2 of a combined spec.
msxml2 implemented a language that had a passing resemblance to the
transformation language in the XSL draft of December '98. Even if it had
been a faithful implementation of that draft, releasing an implementation
of a draft spec in a full non-beta release of a piece of software
distributed to 90% of the world's desktops was a mistake, although at
the time I think many of us thought it was probably a good thing,
spreading the word... It's easier to take a different view with hindsight.

Post by M. David Peterson
I would tend to think that the W3C has made the necessary changes to
ensure that this kind of thing doesn't take place again

I don't think the W3C process can have any effect on such
things. Companies (or people) will take commercial decisions on whether
to release (or use) software based on a draft spec. If they do release
such software again they will take commercial decisions about whether
to change the software as later drafts come out.
David
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
http://www.star.net.uk
________________________________________________________________________
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
--~--

--
<M:D/>

:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Oleg Tkachenko]

Post by David Carlisle
Even if it had
been a faithful implementation of that draft, releasing an implementation
of a draft spec in a full non-beta release of a piece of software
distributed to 90% of the world's desktops was a mistake

Are you talking about XSLT 2.0 ? :)

Microsoft learnt that the hard way and that's the reason both XSLT 2 and
XQuery are out. SQL Server will support some minimal "stable" part of
XQuery and that's it. Moreover, as many microsofties say nowadays, they
don't see much requests for client side declarative XML processing tools...
--
Oleg Tkachenko
http://blog.tkachenko.com
Multiconn Technologies, Israel


--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[M. David Peterson]

As it turns out I was completely off my "interpretation rocker" in
regards to the XSLT/FO WD draft split having anything to do with the
current feelings towards XSLT 2.0 on Redmond campus. While I have
gained a bit of a better understanding of things its probably best for
me to do a bit more research before I comment any further...

David, Michael,

Thanks for helping bring a much needed perspective into things!!!

Cheers :)

<M:D/>

Post by Oleg Tkachenko

Post by David Carlisle
Even if it had
been a faithful implementation of that draft, releasing an implementation
of a draft spec in a full non-beta release of a piece of software
distributed to 90% of the world's desktops was a mistake

Are you talking about XSLT 2.0 ? :)
Microsoft learnt that the hard way and that's the reason both XSLT 2 and
XQuery are out. SQL Server will support some minimal "stable" part of
XQuery and that's it. Moreover, as many microsofties say nowadays, they
don't see much requests for client side declarative XML processing tools...
--
Oleg Tkachenko
http://blog.tkachenko.com
Multiconn Technologies, Israel
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
--~--

--
<M:D/>

:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Michael Kay]

Post by M. David Peterson
In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propogated and
a support nightmare to be invoked.

Just to add to DC's reply.

It's a mistake to imagine that Microsoft's WD-xsl processor was a faithful
and accurate implementation of a draft W3C specification. The WD-xsl
language actually bears no more relationship to the Dec 1998 draft of the
language than it does to the final Dec 1999 spec. This is partly because the
Dec 1998 draft is peppered with descriptions of open issues: anyone
implementing it had to make their own decisions on how to resolve these.
It's quite clear to anyone reading that draft that it was in a very
unfinished state. Many features of WD-xsl bear no resemblence to anything in
any W3C draft: you can search in vain for operators such as $and$ or for the
functions that access the context stack. These features were added by
Microsoft because the W3C draft was incomplete.

To suggest that W3C had a complete specification, that Microsoft implemented
it in good faith, and that W3C then changed it at the last minute, is
therefore a complete distortion. I don't know what motivated Microsoft to
ship product at the time they did, but it was obvious to any observer at the
time that they were basing their product very loosely on a specification
that was incomplete and still changing. It was evident to me as an outsider,
and would have been even more evident to someone with access to the WG
minutes, which I have since seen. The WG was making radical changes at every
single meeting, often without a written proposal on the table, and Microsoft
were members so they would have known that.

Michael Kay
http://www.saxonica.com/



--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[M. David Peterson]

Wow! I had a totally different understanding that was obviously based
on some bad information. Either that or I simply misunderstood the
particular source that expanded upon why XSLT 2.0 was a dead issue at
MS until such time as the draft became final. I'm guessing the latter
as I know the source in which passed this info on to me to be
completely trustworthy and reliable so I simply must have
misinterpreted the comments to mean one thing when they meant
something completely different.

I will see if I can gain some clarification comments and post them if
this is something that would be considered kosher from the source in
which they are obtained.

Thanks for the expanded understanding Dr. Kay!

Post by Michael Kay

Post by M. David Peterson
In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propogated and
a support nightmare to be invoked.

Just to add to DC's reply.
It's a mistake to imagine that Microsoft's WD-xsl processor was a faithful
and accurate implementation of a draft W3C specification. The WD-xsl
language actually bears no more relationship to the Dec 1998 draft of the
language than it does to the final Dec 1999 spec. This is partly because the
Dec 1998 draft is peppered with descriptions of open issues: anyone
implementing it had to make their own decisions on how to resolve these.
It's quite clear to anyone reading that draft that it was in a very
unfinished state. Many features of WD-xsl bear no resemblence to anything in
any W3C draft: you can search in vain for operators such as $and$ or for the
functions that access the context stack. These features were added by
Microsoft because the W3C draft was incomplete.
To suggest that W3C had a complete specification, that Microsoft implemented
it in good faith, and that W3C then changed it at the last minute, is
therefore a complete distortion. I don't know what motivated Microsoft to
ship product at the time they did, but it was obvious to any observer at the
time that they were basing their product very loosely on a specification
that was incomplete and still changing. It was evident to me as an outsider,
and would have been even more evident to someone with access to the WG
minutes, which I have since seen. The WG was making radical changes at every
single meeting, often without a written proposal on the table, and Microsoft
were members so they would have known that.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
--~--

--
<M:D/>

:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Michael Kay]

This is essentially a risk assessment question: it depends on whether the
value you gain from using 2.0 is greater than the sum of the risks, where
risk is measured by the probability of failure multiplied by the cost of
failure.

You've had several responses with different views on the probability of
failure, but to make a decision you need to assess the other two variables,
and it's unlikely that anyone but you can do that.

I think we're starting to see one risk disappear, namely the risk of being
locked into a single supplier. There are now three XSLT 2.0 processors
released, and I'm sure we'll see others in the next few months. (I have no
idea, of course, what quality they will be.)

I think the risk of seriously disruptive changes to the spec is now
reasonably low. There will be minor changes, but I'm pretty confident they
will be easy enough to absorb for a typical project. The working groups are
now spending nearly all of their time discussing edge cases - examples from
the last meeting include how to handle leap seconds, whether or not it's
legal to write "10 div 3" without the first space, whether or not the
numeric literal 1.0e10000 is an error, whether tokenize() applied to an
empty string returns an empty string or an empty sequence, whether
resolve-uri() should reference RFC 2396 or RFC 3896, how lax validation
handles an xsi:type attribute, whether (1 div 0) is a static error or a
dynamic error. Frankly, none of these are things that will affect the
outcome of more than 1% of stylesheets. But of course, committees are not
always predictable: there can be a tendency for new people at a higher level
of management to get involved at the last minute and this can sometimes rock
the boat.

There is of course a contingency plan for a project if the spec does change:
you can carry on using the software that exists today.

I'm personally seeing a lot of projects where the gain from using XSLT 2.0
far exceeds the potential pain. But I wouldn't advise every project to use
it: on a billion-dollar project, it's always worth erring on the side of
caution.

Michael Kay
http://www.saxonica.com/

-----Original Message-----
Sent: 08 March 2005 18:26
Subject: [xsl] Is there a reason for not using XSLT 2.0 as a default
Hi,
I have a question that calls for informed opinion: is
there a reason
for not using xslt 2.0 for most processing tasks? I'm thinking
especially privatish, and pre-processed things rather than on-the-fly
commercial applications.
The standard is now pretty stable, correct? and the
processors seems to
be working well. Saxon 8b-3 is very good, and since Saxon 6.5.3 has a
bug that seems to stop it writing properly in Service pack two XP
machines, it may be a good time to switch anyway.
No doubt a trivial question, but I'd be interested in
hearing what
people think. I'm engaged in a couple of new project involving xslt
where the question of 1.0 or 2.0 is real.
-dan
--
Daniel Paul O'Donnell, PhD
Associate Professor of English
University of Lethbridge
Lethbridge AB T1K 3M4
Tel. [phone]
Fax. [phone]
Home Page <http://people.uleth.ca/~daniel.odonnell/>
The Digital Medievalist Project: <http://www.digitalmedievalist.org/>
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
--~--

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[David Carlisle]

Post by Daniel O'Donnell
The standard is now pretty stable, correct?

That can't be guaranteed, XSLT 1.1 was just abandoned for example.
I imagine that after this length of time the WG aren't keen to do any
major redesign, but to assume stability at this stage is to assume that
the public common process won't be taken seriously.

That said, I'm using xslt2 more and more, but I'd written quite a lot of
XSLT1 before that was finalised as well.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[J***@s-s-t.com]

I've been using XSLT 2.0 and the various versions of Saxon 8 since July of
2004. I've had very little trouble with either. Dr. Kay fixed the one bug
I found in Saxon 8 within a day (and I had already thought of a
work-around).

I can see two issues. First, you'll tie yourself to a single vendor.
That's not much of an issue, since you would probably pick a single vendor
anyway and since Saxonica is a fine vendor. Second, the 2.0 specification
may change before it is finalized. However, that risk seems to be low, as
the working group is winding down (so I gather anyway).

I have been solving problems for my clients without undue difficulty (and
often much more easily than I could with XSLT 1) for 8 months now. Based
on my experience, I recommend that you go with Saxon 8 and XSLT 2.0.

Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)




Daniel O'Donnell <***@uleth.ca>
03/08/2005 12:26 PM
Please respond to
xsl-***@lists.mulberrytech.com


To
xsl-***@lists.mulberrytech.com
cc

Subject
[xsl] Is there a reason for not using XSLT 2.0 as a default






Hi,
I have a question that calls for informed opinion: is
there a reason
for not using xslt 2.0 for most processing tasks? I'm thinking
especially privatish, and pre-processed things rather than on-the-fly
commercial applications.
The standard is now pretty stable, correct? and the
processors seems to
be working well. Saxon 8b-3 is very good, and since Saxon 6.5.3 has a
bug that seems to stop it writing properly in Service pack two XP
machines, it may be a good time to switch anyway.
No doubt a trivial question, but I'd be interested in
hearing what
people think. I'm engaged in a couple of new project involving xslt
where the question of 1.0 or 2.0 is real.
-dan
--
Daniel Paul O'Donnell, PhD
Associate Professor of English
University of Lethbridge
Lethbridge AB T1K 3M4
Tel. [phone]
Fax. [phone]
E-mail <***@uleth.ca>
Home Page <http://people.uleth.ca/~daniel.odonnell/>
The Digital Medievalist Project: <http://www.digitalmedievalist.org/>


--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--




--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Pawson, David]

--
From: Michael Kay
You've had several responses with different views on the
probability of failure, but to make a decision you need to
assess the other two variables, and it's unlikely that
anyone but you can do that.

I think we're starting to see one risk disappear, namely
the risk of being locked into a single supplier. There are
now three XSLT 2.0 processors released, and I'm sure we'll
see others in the next few months. (I have no idea, of
course, what quality they will be.)

Confused Michael. Yours, Colins and .....?

Whose is the third please?

regards DaveP
--
DISCLAIMER:

NOTICE: The information contained in this email and any attachments is
confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.

RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants. However, it
cannot accept any responsibility for any such which are transmitted.
We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk




--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[M. David Peterson]

Saxon.NET is a possibility although that is really just Saxon
recompiled via IKVMC... The other possibility could be Altova but I'd
best not get started on my opinion on their offering. There's also
Oracle and in Dr. Kays XSLT 2.0 book he refers to the Apache project
although I have not seen the results... I did speak with Sam Ruby in
regards to this back in October and he mentioned a recent resurgence
in activity on Xalan so I can only assume that between these two
authority figures obviously there is some work taking place in that
space.

So that makes:

Saxon
Gestalt
Saxon.NET (???)
Altova (????????????????)
Oracle
Apache (?)

Any comments/missing projects?

I should note that with the release of Saxon-B 8.3 that incorporates
the latest working draft changes I have felt more confident that the
time is right to begin the C# port of Saxon and as such it is
beginning to take shape. But until I have a chance to sit down with
Dr. Kay in email to get a better feel for what he wants to see happen
for this second phase of the project as well as seek the advice of the
Saxon community via the saxon-help list I can't really say when this
will become available...


On Wed, 9 Mar 2005 08:45:51 -0000, Pawson, David

Post by Pawson, David
--
From: Michael Kay
You've had several responses with different views on the
probability of failure, but to make a decision you need to
assess the other two variables, and it's unlikely that
anyone but you can do that.
I think we're starting to see one risk disappear, namely
the risk of being locked into a single supplier. There are
now three XSLT 2.0 processors released, and I'm sure we'll
see others in the next few months. (I have no idea, of
course, what quality they will be.)
Confused Michael. Yours, Colins and .....?
Whose is the third please?
regards DaveP
--
NOTICE: The information contained in this email and any attachments is
confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.
RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants. However, it
cannot accept any responsibility for any such which are transmitted.
We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.
RNIB Registered Charity Number: 226227
Website: http://www.rnib.org.uk
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
--~--

--
<M:D/>

:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Michael Kay]

Post by Pawson, David
Confused Michael. Yours, Colins and .....?
Whose is the third please?

XML Spy 2005

Michael Kay



--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Michael Champion]

"M. David Peterson" wrote:
Date: Tue, 8 Mar 2005 17:32:48 -0700

"In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propogated and
a support nightmare to be invoked. "

I was not at Microsoft nor involved with the XSLT WG in 1998-1999, but
my understanding is similar to those who replied that the XSL-FO /
XSLT split had nothing to do with MS shipping an XSLT implementation
that was incompatible with the eventual Recommendation. There were
some interesting points raised in the replies, and I really have no
opinion about their historical accuracy or fairness.

I can only speak to the *current* perception in the WebData XML team
at MS about the lessons we as a company and an industry learned from
this experience. The sense I get from my colleagues who were around is
that it *was* a good faith effort to implement what they understood to
be the draft spec, along with various improvements to make it suitable
to known customer needs. I will say that my personal view at the
time was that Microsoft's support for XSLT, flawed and premature
though it clearly was in hindsight, was an attempt to do the Right
Thing. Furthermore, it had the result of offering considerable
credibility to XSLT and creating a demand for XSLT tools and
experience.. I can very easily imagine a world in which XSLT shared
the fate of XLink, if MS had waited for the final spec and for
customer demand to emerge before supporting it in its core products.

The MS position going forward is, as I understand it from my rather
brief experience, NEVER AGAIN -- we will not ship support of a draft
Recommendation in actual products. That is why we removed the preview
implementation of XQuery from the .NET 2.0 framework, that is why we
are waiting until XSLT 2.0 is actually a Recommendation before
announcing any implementation plans or schedule. (XQuery in SQL
Server is a bit of a special case ... in any event we're not claiming
to ship a conformant implementation, just something that leverages the
years of experience that have gone into XQuery and meets pressing
customer needs).

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Wendell Piez]

Hi Mike,

Post by Michael Champion
I can only speak to the *current* perception in the WebData XML team
at MS about the lessons we as a company and an industry learned from
this experience. The sense I get from my colleagues who were around is
that it *was* a good faith effort to implement what they understood to
be the draft spec, along with various improvements to make it suitable
to known customer needs.

Arguing over whether the effort was in good faith isn't and wasn't very
germane. Like you, I assumed the effort was good-faith -- which only made
me more disappointed when I discovered what the implementation actually
did. In particular, the "various improvements to make it suitable to known
customer needs" were problematic, as they were impossible to disentangle
from the parts that had once been a WD. (And this was after engineers at MS
had helped to define the namespace mechanism.) The upshot was that from the
point of view of developers to whom standards conformance mattered -- and
not even for the portability of the code (at that early point), but only
for the applicability of the knowledge we were acquiring -- the
implementation was sadly crippled. To rely on it at all seemed like going
to France to try and learn Italian. Not, by definition, impossible -- it's
true French is somewhat like Italian, as languages go: but one could also
stay in New York, or even download a copy of XT and go to Italy.

Post by Michael Champion
Furthermore, it had the result of offering considerable
credibility to XSLT and creating a demand for XSLT tools and
experience.. I can very easily imagine a world in which XSLT shared
the fate of XLink, if MS had waited for the final spec and for
customer demand to emerge before supporting it in its core products.

It's generous of you to think so, but I think this is overstating the case.
XLink is an entirely different kettle of fish (it wasn't and isn't very
clear where it belongs: it perhaps should have been part of a modular
HTML+++, or of XSL-FO) and didn't have an XT -- or an (albeit small)
community of DSSSL users eager to put it through its paces. The usefulness
of XSLT was dazzlingly clear, and web sites with XT behind them appeared
almost immediately.

But why is this relevant? The motives of MS back in 1999, or the effects of
the decisions they made then -- all we can do is learn from experience.
Experience teaches us "caveat emptor" -- even when we have little reason to
believe the vendor is not acting in good faith.

Post by Michael Champion
The MS position going forward is, as I understand it from my rather
brief experience, NEVER AGAIN -- we will not ship support of a draft
Recommendation in actual products.

Probably as wise now as it would have been then.

Post by Michael Champion
That is why we removed the preview
implementation of XQuery from the .NET 2.0 framework, that is why we
are waiting until XSLT 2.0 is actually a Recommendation before
announcing any implementation plans or schedule. (XQuery in SQL
Server is a bit of a special case ... in any event we're not claiming
to ship a conformant implementation, just something that leverages the
years of experience that have gone into XQuery and meets pressing
customer needs).

I hope it's not being labeled "XQuery" then (if it's not conformant, it's
not XQuery, right?) ... after having resolved not to make the same mistake
twice. :->

Regards,
Wendell


======================================================================
Wendell Piez mailto:***@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: [phone]
Suite 207 Phone: [phone]
Rockville, MD 20850 Fax: [phone]
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Pieter Reint Siegers Kort]

Thanx all, especially our two Michaels, that was good to read :-)

that is why we are waiting until XSLT 2.0 is actually a Recommendation

before announcing any implementation plans or schedule

O, do I read some kind of "we'll come up with XSLt 2.0"? :-)

XQuery in SQL Server is a bit of a special case...

Hey, common, tell us more - what is supposed to be a "stable" subset of
XQuery?

My personal experience with WD-xsl was just great, I remember entering the
XML world at that time, and thought MS did a great thing to bring early XSL
support. I just updated my stylesheets when newer versions of MSXML came
out, and never have had a real headache in doing it - mine were always small
and simple ones :-)

I think that after all, with all that has happened, I think that MS took a
good decision in not bringing WD's in their products anymore, they show
they've learnt their lessons, and I'm confident that they'll come up with
both XQuery 1.0 AND XSLT 2.0 (right? :) when the Rec specs are there. Wasn'
that Q1 2006, or something? Good, then we have (at least) one year to go,
that's not much.

We at Saxon.NET will be starting the port of Saxon real soon now.

Cheers,
<prs/>

-----Original Message-----
From: Michael Champion [mailto:***@gmail.com]
Sent: Miércoles, 09 de Marzo de 2005 10:03 a.m.
To: xsl-***@lists.mulberrytech.com
Subject: Re: [xsl] Is there a reason for not using XSLT 2.0 as a default

"M. David Peterson" wrote:
Date: Tue, 8 Mar 2005 17:32:48 -0700

"In fact one of the primary reasons Microsoft has held back from providing
direct support for the XSLT 2.0 spec is based on the last second 'split' of
the 1.0 spec into the XSL (FO) and XSLT specifications causing an
incompatible processor to be propogated and a support nightmare to be
invoked. "

I was not at Microsoft nor involved with the XSLT WG in 1998-1999, but my
understanding is similar to those who replied that the XSL-FO / XSLT split
had nothing to do with MS shipping an XSLT implementation that was
incompatible with the eventual Recommendation. There were some interesting
points raised in the replies, and I really have no opinion about their
historical accuracy or fairness.

I can only speak to the *current* perception in the WebData XML team at MS
about the lessons we as a company and an industry learned from this
experience. The sense I get from my colleagues who were around is that it
*was* a good faith effort to implement what they understood to be the draft
spec, along with various improvements to make it suitable
to known customer needs. I will say that my personal view at the
time was that Microsoft's support for XSLT, flawed and premature though it
clearly was in hindsight, was an attempt to do the Right Thing.
Furthermore, it had the result of offering considerable credibility to XSLT
and creating a demand for XSLT tools and experience.. I can very easily
imagine a world in which XSLT shared the fate of XLink, if MS had waited
for the final spec and for customer demand to emerge before supporting it in
its core products.

The MS position going forward is, as I understand it from my rather brief
experience, NEVER AGAIN -- we will not ship support of a draft
Recommendation in actual products. That is why we removed the preview
implementation of XQuery from the .NET 2.0 framework, that is why we are
waiting until XSLT 2.0 is actually a Recommendation before announcing any
implementation plans or schedule. (XQuery in SQL Server is a bit of a
special case ... in any event we're not claiming to ship a conformant
implementation, just something that leverages the years of experience that
have gone into XQuery and meets pressing customer needs).

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--

[Andrew Welch]

Wasn't the real mistake that Microsoft made with MSXML was the whole
side-by-side/replace mode fiasco? Many people would've missed wd-xsl
altogether had replace mode been the default. I believe it was only
with good intentions that the side-by-side installation was invented
(they didn't want to break existing code) but with hindsight that was
wrong decision.

cheers
andrew

--~------------------------------------------------------------------
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-***@lists.mulberrytech.com>
--~--