I don't see what is unfortunate about people using XSLT 1.0. I don't see why
people dislike the fact that others are using it.
It may be more fun to write in newer versions of the language. There are
certainly useful capabilities in XSLTs 2 and 3, and for new applications that
need those capabilities it is wonderful that they are available.
The implication that users SHOULD rewrite existing, working, code whenever
there is a newer better way that it could have been written had it been done
years later is ABSURD.
XML was successful BECAUSE it worked in existing systems. XML is a bit warty
because it was written to make it backward compatible with SGML, so that it
would work in existing systems and thus could be relatively rapidly adopted.
The use case for XML almost always includes longevity and application
independence. We, the XML community, exist because we are able and willing to
accommodate our history.
I once heard a wonderful story about a presentation made by an IT department to
the production department of a publisher. It was all about the new system they
were developing and how wonderful it would be. And, in order to free the needed
resources to develop the new system, they were going to freeze the legacy
system. No new requests for capabilities or even bug fixes would be accepted
for the legacy system; they were focussing on the future. After the
presentation, the CEO of the organization asked them to give that presentation
again, except instead of calling it the "legacy system" they should talk about
it as the "revenue system". Now, how many of you think it is acceptable to
freeze the revenue system?
It seems to me that if you want to stop maintaining parts of your user's
Revenue Systems, you should be very careful to give them good instructions on
how to move to tools YOU prefer, and remember that you may be imposing
significant risks and costs on your customers.
-- Tommie
On Nov 23, 2020, at 10:43 AM, Willem Van Lishout
willemvanlishout(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
I have to agree with the others. XSLT 1.0 is unfortunately still very
prevalent, and I sometimes need to use MSXML to see what quirks it produces.
(There's quite a few of them!)
If you are really keen on removing them, I would at least consider making
them available as easily installable plugins.
By the way, Geert, I don't think MSXML supports debugging, at least in my
Oxygen version it switches to Saxon when I try that.
On Nov 23, 2020, at 15:26, "Geert Bormans
geert(_at_)gbormans(_dot_)telenet(_dot_)be"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Hi Octavian,
Thanks for the update
As much as I don't like it...
some customers can not or don't want to migrate to an XSLT version higher
than 1.0,
and I am not always in a position to change that (and that will continue to
be so for a long while I am afraid)
So I guess I will be needing debugging support for at least Xalan and msxml
4.0 or .net for some time to come,
it is what it is :-(
configuring them as external processors, does not give me real debugging
support, does it
Met vriendelijke groeten,
Best regards,
Geert Bormans
----- Op 23 nov 2020 om 14:47 schreef Octavian Nadolu
octavian_nadolu(_at_)sync(_dot_)ro
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>:
Hello,
Thanks for your feedback.
We intend to update the Saxon 9 and 10 plugins for the Oxygen XML Editor
23.0. Because this are provided separately as plugins, we can updated them
also after the release.
We decided to deprecate some of the XSLT processors (Xalan, MSXML 4.0, MSXML
.NET, .NET 1.0, .NET 2.0 ...) because we do not want to maintain them in the
future. We are not sure if we will remove them completely or just mark them
as deprecated. But we will maintain the XSLT 1.0 support in Oxygen. Also, you
can configure them as external processors.
How many of you are using this processors?
Best Regards,
Octavian
On 23.11.2020 10:46, Mukul Gandhi gandhi(_dot_)mukul(_at_)gmail(_dot_)com
wrote:
On Sun, Nov 22, 2020 at 12:44 PM Mukul Gandhi
gandhi(_dot_)mukul(_at_)gmail(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
I can see that, at the preferences oXygen page, XSLT 1.0 dropdown shows Xalan
as deprecated. It seems to me that, in a future oXygen version, when Xalan
would be removed from the standard oXygen XSLT 1.0 options, one could still
use Xalan with oXygen by specifying it on the 'Custom Engines' option.
Apologies, that I forgot to mention that, I tried oXygen XML Editor version
23.
--
Regards,
Mukul Gandhi
XSL-List info and archive
EasyUnsubscribe ( by email)
--
Octavian Nadolu
<oXygen/> XML Editor
http://www.oxygenxml.com
XSL-List info and archive
EasyUnsubscribe ( by email)
XSL-List info and archive
EasyUnsubscribe ( by email)
XSL-List info and archive
EasyUnsubscribe (by email)
======================================================================
B. Tommie Usdin
mailto:btusdin(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc.
https://www.mulberrytech.com
17 West Jefferson Street
Phone: 301/315-9631
Suite 207
Direct Line: 301/315-9634
Rockville, MD 20850
Fax: 301/315-8285
--------------------------------------------------------------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in XML for Prose Documents
======================================================================
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--