Project

Profile

Help

Feature #3589

Updated by Michael Kay over 3 years ago

As a developer and consultant, I wish to deliver XSLT 2.0+ and XSD 1.1 solutions    to customers and clients via JavaScript. 


 


 ### Server-side 

 

 Node.js interest and adoption have reached noteworthy levels among enterprise customers. 

 

 * It is easier to introduce XSLT and other Saxon XML solutions into an organization that has adopted Node.js when a pure, full JavaScript implementation of those solutions is available. 

 

 * Architectural design of solution systems is simplified when a new platform (Java or .NET) needn't be introduced just for XML technology.   


   


 ### Client-side 

 

 As an aficionado of functional, declarative, and rule-based paradigms, I would love to develop for my clients in Lisp or any number of non-imperative languages that are unfortunately permanently niche-bound now.    Similarly, I see technical merit to Saxonica's Saxon-CE and (current) Saxon-JS design decisions in the browser.    However, socially it is simply not happening:    General UIs are not being written in XSLT in the browser and never will be to any significant extent in production settings. 


 


 Where XSLT still _could_ offer value in the browser is in the delivery of local, platform-independent checking and transformation of XML documents.    No event processing model.    No reliance on browser vendor support for proper parsing or serialization.    Just pure W3C standards adherence, implemented in JavaScript so it can be distributed to and run by clients without installation. 


 


 Web app GUIs can be written via many strong frameworks atop JavaScript in the browser.    Saxon-JS can't compete in that arena.    Saxon-JS can compete and win by delivering the real strength of XSLT, XML-to-XML transformation, to the edges of the network: 


 


 * Work is offloaded from central servers, reducing performance bottlenecks and processing costs. 

 

 * Sensitive data need never leave customer premises. 

 

 * Network bandwidth usage is reduced when the size of the data being transformed greatly exceeds the size of the XSLT code and libraries (yes, including parsing and serializing components). 
 

Back