XSLT

Since 1999 XSLT has become a mainstream W3C standard high level language for XML processing.  The typical processing tasks include transformation to HTML, generation of specialized document views, sorting and search. Compared to traditional programming languages XSLT greatly increases programmer productivity: simple tasks are programmed quickly, and more complicated ones are solved incomparably faster than if Java or C/C++ was used. Many excellent textbooks are available and the number of knowledgeable, experienced XSLT programmers grows steadily. Open source, reference implementations stimulate XSLT’s adoption.

In our view the term 'transformation' has too narrow connotations. In reality XSLT is being used to perform data processing tasks such as searching, sorting, extraction of information, and also transformations in the common sense: systematic re-expression of source information into a different form. There is therefore a multitude of applications for the language beyond formatting. As a corollary, the output of a transformation doesn't need to be necessarily text: the output can be e.g. direct graphical actions, creation of an index, etc. 

As more and more of the world’s data is created, stored, transmitted, and processed in XML formats, the need to process the data with the aid of a rich, high level, programming language such as XSLT arises more often and in more places as newer IT system architectures embrace XML data streams. More often than in the previous “early adopter” stage—XML needs to be processed on-line: in response to dynamic demand—an opportunity to streamline an IT process. Care must be taken to avoid creating performance bottlenecks than can effectively block scalability.

The flip side of XSLT’s richness is the difficulty of building high performance implementations. It is relatively easy, if tedious, to implement a proof-of-concept XSLT processor by following the W3C spec, but very hard to create a really fast one. This was also true of symbolic languages of Artificial Intelligence, and of early Java implementations. Luckily, steady progress in compilation techniques  to make all these powerful languages practical for demanding applications.

Ambrosoft’s ambition is to lead the efforts in optimized XML high level language processing and the new GREGOR compiler is a major step in this direction. GREGOR is not an interpreter but a true compiler: it synthesizes new code to reflect an input XSLT stylesheet’s logic. GREGOR is architected differently from its Open Source predecessor (XSLTC): it is modular, with a new optimization stage and the ability to emit compilation results in more than one format. In fact,  in addition to generating Java bytecodes, GREGOR is expected to emit ’C’ code in early 2003 for maximum performance and integration with existing C/C++ frameworks of our customers. The framework can be applied to XQuery; implementation will follow demand.

Wireless data services

We believe that there is a strong synergy between the emergence of XML as the way to express content, web services, and the potential of handheld devices that participate in the world of information via wireless internet connections. In a simple but fundamental scenario a wireless handheld receives XML documents over a wireless link and then runs client-side transformations to produce a variety of "views" of the information. The transformations may sort information by a variety of criteria, they may suppress or expand information, etc. Most importantly, the views are produced on the handheld itself without incurring server roundtrip latencies or unnecessary bandwidth utilization: the interactive application responds fast.

How can this happen? By utilizing Gregor/XSLT translets that process XML information speedily and in small memory footprint. Gregor (and its Open Source predecessor) has been designed from ground up as an agile, small memory XSLT solution.

Gregor solution for wireless data services has the following benefits:

1. XML data processing logic can be written in XSLT
2. there is no need for an XSLT processor on the device nor for stylesheets in text form
3. highly optimized translets produce results fast enough for interactive application responsiveness
4. one document obtained in a single download can be designed to carry information supporting multiple views
5. when coupled with Gregor Server XML data content can be additionally custom compressed making for faster downloads and the possibility to cache more documents on the small device. For instance: a sample Universal Business Language (UBL) Order form document is 5074 bytes long; the browsable HTML view of this document is about 31,000 bytes (on today's Verizon Wireless CDPD network the HTML would load in approx. 30 seconds). The Gregor compact form of the source XML document is 697 bytes and so would load in half a second. The compression factor is over 7 for XML and over 44 (!) for the browser viewable HTML form. In addition, the binary XML supports multiple visualizations, calculations, etc. (XML repurposing).
6. in this case (of using compressed binary XML) no XML parser is needed on the client either
7. new translets can be downloaded over the same wireless link, supporting the solution's deployment, maintenance, and evolution

This is how the example UBL document looks like after a Gregor translet transforms it to HTML displayed here in the Opera browser on a Zaurus SL5500 handheld.

Check out the new demo applet at our WirelessDemo.

XML transformations on the server

As newer IT systems encounter more and more data in XML form and their architectures begin to require on-line, dynamic demand based XML processing performance bottleneck are easily created.  The Open Source reference implementations of XSLT will inevitably no longer be sufficient to sustain heavier loads. The system builder has the following options:

1. give up XSLT (and lose the programmer productivity/agility benefits)

2. invest in multiplying hardware boxes (and create more maintenance needs + end up with additional quickly aging iron)

3. buy Gregor/XSLT licenses from Ambrosoft (and enjoy hardware upgrades orthogonally)

We work very hard to make the third option work for you.

[ Home ]

Send mail to info@ambrosoft.com with questions or comments about this web site.
Copyright © 2008 Ambrosoft, Inc.
Last modified: March 07, 2008