Douglas F. Parkhill is a Canadian technologist and former research minister, best known for his pioneering work on what is now called cloud computing, and his work on Canada's Telidon videotex project. He started working at the Canadian ministry of Communications (now part of the Department of Trade and Industry) in 1969, having previously worked at the Mitre Corporation. He was responsible for many activities in communications satellites, computer communications, command and control systems and telecommunications. He was winner of the Treasury Board of Canada Secretariat's Outstanding Achievement award in 1982, the Conestoga shield for services to government and industry in computer communications research and development, the Touche Ross award for Telidon development. He was an author of several publications including the 1966 book, The Challenge of the Computer Utility. In the book, Parkhill thoroughly explored many of the modern-day characteristics of cloud computing (elastic provisioning through a utility service) as well as the comparison to the electricity industry and the use of public, private, government and community forms. The book won the McKinsey Foundation award for distinguished contributions to management literature. He worked with Dave Godfrey, the Canadian writer and novelist on a later book Gutenberg two about the social and political meaning of computer technology. He was in charge of research at the Federal Department of Communications at the time when the department was funding development of the Telidon videotext system, was heavily involved in promoting the system, and had overall control of the program. In a radio broadcast in 1980, he outlined some of the potential of the system, from financial information, to theatre reservations, with the ability to pay and print out tickets from the system. He later documented the history of the Telidon project, and the history of videotext in general. == Publications == The Challenge of the Computer Utility, Addison-Wesley, 1966, ISBN 0-201-05720-4 edited with Dave Godfrey, Gutenberg Two: The New Electronics and Social Change, Press Porcepic, 1979, ISBN 0-88878-191-1 The Beginning of a Beginning. Ottawa; Department of Communications, 1987. A history of the Telidon project.
Feng Office Community Edition
Feng Office Community Edition (formerly OpenGoo) is an open-source collaboration platform developed and supported by Feng Office and the OpenGoo community. It is a fully featured online office suite with a similar set of features as other online office suites, like Google Workspace, Microsoft 365, Zimbra, LibreOffice Online and Zoho Office Suite. The application can be downloaded and installed on a server. Feng Office could also be categorized as collaborative software and as personal information manager software. == Features == Feng Office Community Edition main features include project management, document management, contact management, e-mail and time management. Text documents and presentations can be created and edited online. Files can be uploaded, organized and shared, independent of file formats. Organization of the information in Feng Office Community Edition is done using workspaces and tags. The application presents the information stored using different interfaces such as lists, dashboards and calendar views. == Licensing == Feng Office Community Edition is distributed under the GNU Affero General Public License, version 3 only. == Technology used == Feng Office uses PHP, JavaScript, AJAX (ExtJS) and MySQL technology. Several open source projects served as a basis for development. ActiveCollab's last open sourced release was used as the initial code base. It includes CKEditor for online document editing. == System requirements == The server could run on any operating system. The system needs the following packages: Apache HTTP Server 2.0+ PHP 5.0+ MySQL 4.1+ (InnoDB support recommended) On the client side, the user is only required to use a modern Web browser. == History == OpenGoo started as a degree project at the faculty of Engineering of the University of the Republic, Uruguay. The project was presented and championed by Software Engineer Conrado Viña. Software Engineers Marcos Saiz and Ignacio de Soto developed the first prototype as their thesis. Professors Eduardo Fernández and Tomas Laurenzo served as tutors. Conrado, Ignacio and Marcos founded the OpenGoo community and remain active members and core developers. The thesis was approved with the highest score. In 2008, Viña joined the Uruguayan software development company Moove It. Currently there is a second project for OpenGoo at the same university being developed by students Fernando Rodríguez, Ignacio Vázquez and Juan Pedro del Campo. Their project aims to build an open source Web-based spreadsheet. In December 2009 the OpenGoo name was changed to Feng Office Community Edition.
24SevenOffice
24SevenOffice is a Norwegian software company headquartered in Oslo, Norway, with offices in Stockholm, Sweden and London, United Kingdom. Founded in 1997, the company specializes in web-based (SaaS) ERP and CRM systems. == Company history == 24SevenOffice was founded in 1997 in Porsgrunn, Norway, as IKT Interactive AS and marketed as kontorplassen.no. The name "24SevenOffice" was introduced for the company's London branch when the company entered the British market in 2003. The company changed its name to 24SevenOffice in February 2005. Originally based in Skien, the company later moved to Oslo Innovation Center, then to Tjuvholmen in the waterfront Fjord City of Oslo, and now the headquarters are located in Inkognitogaten 33, Solli plass, Oslo. The idea for the company's product was developed in 1996, and 24SevenOffice was an early innovator in the Scandinavian market in web-based enterprise resource planning solutions (ERP). A British office was established at Surrey Business Park in May 2003, with the company launching its web-based (SaaS) utility computing system to the UK SME market in 2004. An office in Chennai, India, was established in 2005, and 24SevenOffice entered the Swedish market when they acquired the leading competitor and ERP-provider Start & Run in a cash deal. In August 2005, the company had an initial public offering that raised NOK 15 million, and the company entered The Norwegian Over the Counter Market list as of 5 October 2005 (the ticker was 24SO), reaching a market value of NOK 175 million, with 5000 customers in Norway. In 2006, the company signed a deal to sponsor rally driver Petter Solberg, at the time the largest private sponsorship in Norwegian sport. Instead of receiving NOK 5 million in cash, Solberg received a 2.9 per cent ownership in the company. The company entered the German-speaking market in April 2006 when an office in Frankfurt am Main was opened. In late August/early September, they established an office with ten sales agents plus a general manager in Stockholm for the Swedish market. 24SevenOffice initiated strategic cooperation with Active 24 in early 2006 to develop a common platform. During the summer, Active 24 was bought by 24SevenOffice's ERP/CRM competitor Mamut (company), and 24SevenOffice terminated the contract with Active 24 in October demanding NOK 200 million in compensation for lost revenue. After a breakdown of settlement negotiations in the Forliksråd in January 2007, 24SevenOffice filed a case against Active 24 for breach of agreement in the Oslo District Court in March. 24SevenOffice lost on all counts in the District Court in December 2007. In January 2008, 24SevenOffice appealed the case to the Borgarting Court of Appeal, reducing the cause of action from NOK 250 to 30 million. 24SevenOffice lost on all counts in the Court of Appeal in December 2008, and was ordered to cover the costs incurred by Active 24 in connection with the dispute totaling NOK 6.91 million. 24SevenOffice appealed the case to the Supreme Court of Norway, but the Supreme Court Appeals Committee in March 2008 unanimously rejected the appeal from 24SevenOffice over the Borgarting Appeal Court's unanimous judgment of December 2008. On a counterclaim from Active 24 and Mamut against 24SevenOffice, the Oslo District Court in May 2010 found, that 24SevenOffice should pay Active 24 NOK 12 million in compensation for wrongfully having terminated the agreement, and a further NOK 360.000 of the opponent's legal costs. 24SevenOffice disagreed with the court ruling, and appealed once again. The Borgarting Court of Appeal in November 2011, ruled to reduce the amount of damages to NOK 4.4 million plus NOK 900.000 in penal interest. With several scrip issues, 24SevenOffice raised 25 million NOK (about $4 million at the time) between October 2005 and July 2006. They entered into a strategic partnership with Bluegarden, who for 30 years had delivered digital services for payroll, human resource planning, recruitment and training, in March 2006, and they made a large-scale agreement in April 2006, with US telecommunications software company Webex, a competitor to Norwegian Tandberg videoconferencing equipment manufacturer. In September 2006, 24SevenOffice signed an agreement with Fokus Bank to provide their customers with extended functionality in Internet banking. 24SevenOffice had by 2007 reportedly 9000 customers, joined the OpenAjax Alliance, and entered into a strategic partnership with Dun & Bradstreet in May 2007, but despite getting listed on Oslo Axess on 22 June (ticker: TFSO), reaching a market capitalization of NOK 120 million, the company was still losing money. The company ended 2007 with a revenue of NOK 21.7 million. In 2008, 24SevenOffice bought 50% of the stocks in telecommunication company Oyatel, partnered with Nets Group to facilitate invoicing for businesses, and telecommunications company Telipol chose 24SevenOffice's second-generation Internet platform for its 8,000 users. They announced an increase in revenues in Q2 to 11.1 million, up from 4.7 million in the same period the year before. 24SevenOffice had a turnover of NOK 37 million in the first half of 2009, a doubling compared to the same period the previous year, and presented its first positive EBITDA in Q2. The Norwegian Association of Auditors signed an agreement with 24SevenOffice in 2011, whereby they only recommend 24SevenOffice as a system for their members to use. On 27 June 2013, the shareholders of 24SevenOffice took off from the stock exchange and privatized the company. In recent years, the company has invested heavily in finance and accounting – and got leading auditing companies such as PwC and KPMG on the customer list. == Products == 24SevenOffice is a web-based (SaaS) ERP system. It includes modules for CRM, accounting, invoicing, e-mail, file/document management and project management. == Awards == 24SevenOffice won the Seal of Excellence in Multimedia Award at the 2004 CeBIT, became Norwegian Gazelle Company of the year 2004, chosen by Dagens Næringsliv and Dun & Bradstreet, won Product of the Year in the Norwegian finance magazine Kapital, and the IKT Grenland Innovation Award in 2008.
Hancom Office
Hancom Office is a proprietary office suite that includes a word processor, spreadsheet software, presentation software, and a PDF editor as well as their online versions accessible via a web browser. It is primarily addressed to Korean users. Hancom Office is written in Java and C++ that runs on Android, iOS, macOS and Windows platforms. == Products == Hangul - Hangul is a word processor developed by Hancom. It is a product that eliminates the inconvenience of the original Hangul word processor, which was limited to Hangul cards or PC models. Originally, the name was written using the '아래아' character, a vowel letter that is obsolete in modern Korean, and it was referred to as 'HWP' (an abbreviation for Hangul Word Processor), '아래아 한글' (Arae-a Hangul), '한/글' (Han/Geul), and so on. Hangul is currently the most widely used word processor in South Korea, often used alongside Microsoft Word. HanWord - word processor compatible with Word HanCell - spreadsheet program HanShow - presentation program Hancom Office Hanword Viewer - For viewing documents created by Hancom Office or Microsoft Office
Cloud-Based Secure File Transfer
Cloud-Based Secure File Transfer is a managed or hosted file transfer service that provides cloud storage that can be accessed via SSH File Transfer Protocol (SFTP). These services allow secure, reliable file transfers while offering the scalability, redundancy, and high availability of cloud infrastructure. == Technical overview == The evolution of file transfer protocols began with File Transfer Protocol (FTP) and SSH File Transfer Protocol (SFTP). SFTP offered enhanced security through the use of SSH (Secure Shell) encryption, which addressed many of the security concerns associated with traditional FTP. Over time, as businesses increasingly adopted cloud infrastructure, the demand for services that integrate secure file transfer with cloud storage led to the rise of Cloud-Based Secure File Transfer services. These services combine the benefits of secure, encrypted file transfer with the scalability and flexibility of cloud-based storage systems. Traditional on-premises SFTP typically involves setting up and managing physical or virtual servers to handle file transfers. In contrast, Cloud-Based Secure File Transfer utilizes managed cloud infrastructure, such as AWS EC2, Azure VMs, or Google Cloud, to automate scaling, ensure redundancy, and provide high availability. These cloud environments can be configured to automatically scale with demand, enabling businesses to handle large volumes of data transfers without the need for extensive physical hardware. == Features == Scalability and availability: Cloud-Based Secure File Transfer services are inherently scalable, with features like load balancing, multi-region deployments, and auto-scaling groups that adjust resources in response to traffic spikes. This ensures that the system can handle varying workloads and provides continuous availability, even during high-demand periods. Cost-effectiveness: By eliminating the need for physical infrastructure and reducing ongoing server maintenance costs, Cloud-Based Secure File Transfer services offer significant cost savings compared to traditional on-premises services. Cloud providers typically offer pay-as-you-go pricing models, where users only pay for the resources they use, further optimizing costs. Security and compliance: Cloud-Based Secure File Transfer products offer strong security measures, including end-to-end encryption, key management, detailed logging, and auditing. These services are often compliant with industry regulations such as HIPAA (Health Insurance Portability and Accountability Act), GDPR (General Data Protection Regulation), and SOC 2 (System and Organization Controls), ensuring that data transfers meet necessary security and privacy standards. == Cloud-Based Secure File Transfer providers == == Uses == Cloud-Based Secure File Transfer is used across various industries to securely transfer sensitive data and integrate into business workflows. In healthcare, Cloud-Based Secure File Transfer is essential for securely transferring electronic Protected Health Information (ePHI), ensuring compliance with regulations like HIPAA. In financial institutions, it is used to protect sensitive financial data during transfer, maintaining privacy and security. Data analytics also benefits from Cloud-Based Secure File Transfer, offering a secure and efficient method for transferring large datasets between systems or partners. Technically, Cloud-Based Secure File Transfer is often integrated into enterprise workflows through automated file transfers, using scripting or APIs. It also plays a key role in cloud backup and disaster recovery, ensuring that files are securely transferred and stored in cloud environments, which supports business continuity. However, businesses must address certain implementation challenges. Despite its secure design, Cloud-Based Secure File Transfer is not immune to risks such as misconfigured SSH keys, improper access control, or inadequate encryption. Regular security audits and careful configuration management are necessary to minimize the risk of data breaches. Additionally, integrating Cloud-Based Secure File Transfer with legacy systems can present challenges, such as incompatible APIs or outdated authentication methods. == Comparisons with related technologies == Cloud-Based Secure File Transfer differs from traditional SFTP primarily in its deployment and management model. Traditional SFTP services are typically hosted on-premises or on virtual servers, requiring manual configuration, ongoing infrastructure maintenance, and security management by in-house IT teams. In contrast, Cloud-Based Secure File Transfer is offered as a Software-as-a-Service (SaaS) service, reducing infrastructure overhead by eliminating the need for dedicated hardware or virtual machines. This model simplifies management through centralized web-based interfaces, automated updates, and built-in scalability. While Cloud-Based Secure File Transfer is focused on providing secure file transfers over the SFTP protocol, Managed File Transfer (MFT) platforms generally support a broader range of protocols, including FTP, FTPS, HTTP/S, and AS2. MFT services often include advanced features such as end-to-end encryption, extensive automation, compliance reporting, and integration with enterprise systems. Cloud-Based Secure File Transfer services may offer some of these features but are typically more lightweight and streamlined, targeting organizations seeking a secure and scalable alternative to traditional SFTP without the full suite of MFT capabilities. As such, Cloud-Based Secure File Transfer can be seen as a specialized subset within the broader managed file transfer ecosystem.
Product-family engineering
Product-family engineering (PFE), also known as product-line engineering (PLE), is based on the ideas of "domain engineering" created by the Software Engineering Institute, a term coined by James Neighbors in his 1980 dissertation at University of California, Irvine. Software product lines are quite common in our daily lives, but before a product family can be successfully established, an extensive process has to be followed. This process is known as product-family engineering. Product-family engineering can be defined as a method that creates an underlying architecture of an organization's product platform. It provides an architecture that is based on commonality as well as planned variabilities. The various product variants can be derived from the basic product family, which creates the opportunity to reuse and differentiate on products in the family. Product-family engineering is conceptually similar to the widespread use of vehicle platforms in the automotive industry. Product-family engineering is a relatively new approach to the creation of new products, recently evolving to Model-Based Product Line Engineering (MBPLE), emphasizing the centrality of a model-centric approach in PLE. It focuses on the process of engineering new products in such a way that it is possible to reuse product components and apply variability with decreased costs and time. Product-family engineering is all about reusing components and structures as much as possible, according to the ISO/IEC 26550/2015 and the latest ISO/IEC 26580/2021 that introduced the concept of feature-based Product Line Engineering. Several studies have proven that using a product-family engineering approach for product development can have several benefits. Here is a list of some of them: Higher productivity Higher quality Faster time-to-market Lower labor needs The Nokia case mentioned below also illustrates these benefits. In 2025 the publishing of the book Model-Based Product Line Engineering (MBPLE): The feature-based path to product lines success by Marco Forlingieri, Tim Weilkiens and Hugo Guillermo Chalé-Gongora formalized the foundation of the discipline, including best practices and new industrial cases. == Overall process == The product family engineering process consists of several phases. The three main phases are: Phase 1: Product management Phase 2: Domain engineering Phase 3: Product engineering The process has been modeled on a higher abstraction level. This has the advantage that it can be applied to all kinds of product lines and families, not only software. The model can be applied to any product family. Figure 1 (below) shows a model of the entire process. Below, the process is described in detail. The process description contains elaborations of the activities and the important concepts being used. All concepts printed in italic are explained in Table 1. === Phase 1: product management === The first phase is the starting up of the whole process. In this phase some important aspects are defined especially with regard to economic aspects. This phase is responsible for outlining market strategies and defining a scope, which tells what should and should not be inside the product family. ==== Evaluate business visioning ==== During this first activity all context information relevant for defining the scope of the product line is collected and evaluated. It is important to define a clear market strategy and take external market information into account, such as consumer demands. The activity should deliver a context document that contains guidelines, constraints and the product strategy. ==== Define product line scope ==== Scoping techniques are applied to define which aspects are within the scope. This is based upon the previous step in the process, where external factors have been taken into account. The output is a product portfolio description, which includes a list of current and future products and also a product roadmap. It can be argued whether phase 1, product management, is part of the product-family-engineering process, because it could be seen as an individual business process that is more focused on the management aspects instead of the product aspect. However phase 2 needs some important input from this phase, as a large piece of the scope is defined in this phase. So from this point of view it is important to include the product-management phase (phase 1) into the entire process as a base for the domain-engineering process. === Phase 2: domain engineering === During the domain-engineering phases, the variable and common requirements are gathered for the whole product line. The goal is to establish a reusable platform. The output of this phase is a set of common and variable requirements for all products in the product line. ==== Analyze domain requirements ==== This activity includes all activities for analyzing the domain with regard to concept requirements. The requirements are categorized and split up into two new activities. The output is a document with the domain analysis. As can be seen in Figure 1 the process of defining common requirements is a parallel process with defining variable requirements. Both activities take place at the same time. ==== Define common requirements ==== Includes all activities for eliciting and documenting the common requirements of the product line, resulting in a document with reusable common requirements. ==== Define variable requirements ==== Includes all activities for eliciting and documenting the variable requirements of the product line, resulting in a document with variable requirements. ==== Design domain ==== This process step consists of activities for defining the reference architecture of the product line. This generates an abstract structure for all products in the product line. ==== Implement domain ==== During this step a detailed design of the reusable components and the implementation of these components are created. ==== Test domain ==== Validates and verifies the reusability of components. Components are tested against their specifications. After successful testing of all components in different use cases and scenarios, the domain engineering phase has been completed. === Phase 3: product engineering === In the final phase a product X is being engineered. This product X uses the commonalities and variability from the domain engineering phase, so product X is being derived from the platform established in the domain engineering phase. It basically takes all common requirements and similarities from the preceding phase plus its own variable requirements. Using the base from the domain engineering phase and the individual requirements of the product engineering phase a complete and new product can be built. After the product has been fully tested and approved, the product X can be delivered. ==== Define product requirements ==== Developing the product requirements specification for the individual product and reuse the requirements from the preceding phase. ==== Design product ==== All activities for producing the product architecture. Makes use of the reference architecture from the step "design domain", it selects and configures the required parts of the reference architecture and incorporates product specific adaptations. ==== Build product ==== During this process the product is built, using selections and configurations of the reusable components. ==== Test product ==== During this step the product is verified and validated against its specifications. A test report gives information about all tests that were carried out, this gives an overview of possible errors in the product. If the product in the next step is not accepted, the process will loop back to "build product", in Figure 1 this is indicated as "[unsatisfied]". ==== Deliver and support product ==== The final step is the acceptance of the final product. If it has been successfully tested and approved to be complete, it can be delivered. If the product does not satisfy to the specifications, it has to be rebuilt and tested again. The next figure shows the overall process of product-family engineering as described above. It is a full process overview with all concepts attached to the different steps. == Process data diagram == On the left side the entire process from the top to bottom has been drawn. All activities on the left side are linked to the concepts on the right side through dotted lines. Every concept has a number, which reflects the association with other concepts. == List of concepts == Below the list with concepts will be explained. Most concept definitions are extracted from Pohl, Bockle, & Linden (2005) and also some new definitions have been added. Table 1: List of concepts == Example == There are some good examples of the use of product family engineering, which were quite successful. The abstract model of product family engineering allows different kinds of uses, most of them are related to the consumer electronics m
XRX (web application architecture)
In software development XRX is a web application architecture based on XForms, REST and XQuery. XRX applications store data on both the web client and on the web server in XML format and do not require a translation between data formats. XRX is considered a simple and elegant application architecture due to the minimal number of translations needed to transport data between client and server systems. The XRX architecture is also tightly coupled to W3C standards (CSS, XHTML 2.0, XPath, XML Schema) to ensure XRX applications will be robust in the future. Because XRX applications leverage modern declarative languages on the client and functional languages on the server they are designed to empower non-developers who are not familiar with traditional imperative languages such as JavaScript, Java or .Net. == Overview of XRX == XRX is a zero translation application architecture that uses XML to store data in the client web browser, on the application server and in the database server. It is because each of these layers uses XML as the same structural data model that XRX applications do not have to translate data structures to and from both object and relational data structures. Because of the lack of need for translation, XRX is considered to have a clean and elegant design. The XRX web application architecture allows developers to focus on the business problem and not the translation problem. XRX benefits from several advances in software technology: === Client Architectural Features === A model–view–controller (MVC) architecture that separates the data from its presentation and business logic. A single element (xf:submission) for all server submissions. This replaces much of the JavaScript code required in most AJAX applications. An advanced event model (XML Events) consistent with W3C standards that frees applications from having to deal with vendor-specific and browser-specific event handling. A Dependency graph that is used to store the dependency structure of the client controllers. This frees the developer from having to manually update either the model or the views when data changes in an application. This allows spreadsheet-like applications to be created on the client with very little effort. A declarative programming style that allows most client XForms applications to be created using a small set of approximately 20 elements. This allows rich client applications to be created without knowledge of JavaScript or other procedural scripting languages. An easy-to-extend system for creating new user interface controls using the EXtensible Bindings Language. This allows developers to add new controls at any time without fear of incompatibilities with W3C standards. === Server Architecture Features === Many native XML databases have built-in REST interfaces making each XQuery inherently a RESTful web service. A functional programming model that promotes side-effect free systems that are easier to debug and easier to run on multiple processors. An easy-to-extend system using XQuery function and modules. === Both Client and Server === Both XRX client and server components support a wide range of XML related standards such as XPath, XML Schema and XML Namespaces. Consistent use of REST interfaces to exchange data between the client and server for all transfers of data including as-you-type data checking and suggest functions. Consistent integration of W3C standards including use of XPath and XML Schema data types. A large library of standard of functions used on both the client and server. == Overall Benefits of XRX == One of the principal benefits of the XRX architecture is that it avoids the requirement to "shred" complex data structures into relational structures and then reconstitute the data back into structures when a record is edited on the client. Another benefits of the XRX Web application architecture is that it avoids most of the problems around the object-relational impedance mismatch. Another advantage is that the client developer does not have to learn JavaScript on the client. == Comparison with Traditional Object/Relational Web Application Architectures == Many traditional web application architectures created in the late 1990 were based on middle object tiers and persistence layers that used tabular data streams and relational database systems. Because each of these layers used different structures to store the models the systems required much additional complexity to translate between layers. == History of XRX == Early examples of using a zero-translation architecture in multi-tier systems can be traced back to the rise of object-oriented databases in the 1990s. See OODBMS History Mark Birbeck suggested that the combination of XForms, XQuery with REST interfaces between the two had many advantages in a meeting to the UK XML User Group in September 2006 . His presentation was one of the first to specifically suggest that the combination of three technologies: XForms and XQuery with REST interfaces would have surprisingly beneficial effects. Mark termed this process "Skimming" but that term did not seem to be contagious. Erik Bruchez of Orbeon spoke at the XML 2007 conference on Boston in December 2007. In his presentation "XForms and the eXist XML database: a perfect couple", Bruchez showed that many people were discovering synergistic benefits of XForms on the client and XQuery on the server. The label for XRX was suggested by a blog posting by Dan McCreary on December 14, 2007. It was in this article that Dan suggested the need for a contagious meme for the ideas behind the XRX architecture. == Generalizations of XRX == Although XRX was originally intended to connote the use of XForms on the client, REST as an interface and XQuery on the server, other proponents of the symmetrical use of XML on the client and server have generalized the term to encompass any XML-centric web client and any server that can store and query XML documents. This use of XRX is generally referred to as "shallow XRX". These generalizations do benefit from a simplified zero-translation architecture but many do not benefit from REST interfaces, XPath for consistent data selection, declarative systems in the client, and functional languages on the server (one of the key aspects of XRX). Use of all three technologies (XForms, REST and XQuery) is referred to as "deep XRX". Although XRX architecture is centred on XForms and XQuery, it does not preclude the use of other technologies that manipulate XML natively, such as XSLT, XProc, and XSL-FO.