Project

Profile

Help

Feature #3589

closed

Saxon-JS should depend only upon JavaScript, not web browsers

Added by Kenneth Hughes about 6 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Build and Release
Sprint/Milestone:
-
Start date:
2018-01-02
Due date:
% Done:

0%

Estimated time:
Applies to JS Branch:
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

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).

Actions #1

Updated by Michael Kay about 6 years ago

Thanks for the feedback. Your thinking is very much in line with our strategic direction. Node.js is a key target for the technology, and to deliver that we need to have a better story on parsing and serialization; but more than that, we need to be able to compile stylesheets within the Javascript environment. To that end we are working on a version of the compiler front-end written in XSLT to make it completely portable.

We also recognize the use case for a client-side configuration in which the event-handling extensions are disabled.

Actions #2

Updated by Michael Kay about 6 years ago

  • Project changed from Saxon to SaxonJS
Actions #3

Updated by Michael Kay over 3 years ago

  • Description updated (diff)
  • Status changed from New to Closed

Fixed with the release of Saxon-JS 2

Actions #4

Updated by Michael Kay over 3 years ago

  • Fixed in JS Release set to Saxon-JS 2.0
Actions #5

Updated by Kenneth Hughes over 3 years ago

Excellent news! Congratulations on the major new release, and thank you!

Actions #6

Updated by Debbie Lockett over 3 years ago

  • Category set to Build and Release

Please register to edit this issue

Also available in: Atom PDF Tracking page