Re: [xsl] [Ann] Oxygen XML Editor version 23 release

I think this is really true, and it’s why XML and XSLT is still so relevant.

The story about replacing the IT Department’s concept of “legacy” (that is, 
tools that the business spends money on in order generate revenue, but that are 
no longer current) with the core business idea of how the business actually 
makes that revenue (and thus continues to exist as a business) is the whole 
ball-game.

It’s the difference between being core to a business and being support, and 
it’s absolutely everything.



> On 24 Nov 2020, at 2:29 am, B Tommie Usdin 
> btusdin(_at_)mulberrytech(_dot_)com 
> <xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
>
> 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/1106500
> or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
> --~--