In 3-tier applications, a programming language is required in order to transform clients' database operations. These transformations are usually done through Java or PHP languages. Nevertheless, these languages may be too complex if constant access to databases is required.

XSQL aims to solve this problem by providing programmers a scriptable, flexible language for middle-tier application systems.

At the beginning of 2000, a language was needed to get around SPL code to the application server area of Axional Studio. This language was also necessary to increase the output of compiled C languages. The most obvious option seemed to be Java, but Java proved to be too complex, in terms of usability, to process databases.

XSQL was originally based on the idea of XML expression language according to XEXPR - A Scripting Language for XML specifications. It came to include characteristics of languages related to 4GL databases, including X/DDL and X/DML database-independent syntax.

XSQL was developed on Java and, as such, it has similar characteristics and also specifies database access functions.

XSQL is used as an interpreted scripting language for Axional Studio application servers. For this reason, it requires an application server to be executed.

A script can be executed by different options depending on the loader. A loader refers to the source of the code. Three types of XSQL script loaders exist:

• Filesystem, where scripts can be loaded by a file system.
• Dictionary, where scripts are loaded by a dictionary database system, (table wic_xsql_scripts ).
• Embed, where the script code is auto content.

A script can be executed by different mechanisms:

• Line command - (filesystem) when the user has an XML script file, the loader can be used to initiate a single server instance. Until it ends, this instance will execute the script. Any user routine that can be used by the main script must be accessible to the loader and thus has to be in the same execution directory.
• HTTP request - (dictionary) scripts are usually executed in the HttpServletRequest sequence associated with a database. In these cases, the loader uses the dictionaries associated to the database where the request is processed in order to obtain the script or an additional function. The client who executes the script, directly or indirectly, may be:
  • WebApp application, from the main object or its components, the transaction event processor, a button or a client-side JavaScript function call.
  • WebOs application and a channel.
  • dbtudio - the database explorer.
• SOAP Request - (dictionary or embed) SOAP system allows users to use scripts directly, including the code as a part of the (embed) call or calling scripts in a dictionary.

The following graph shows the process of a script execution.

• Lexical Conventions - define grammatical conventions in XML.
• Basic Concepts - define elemental language concepts (entry point, etc.).
• Data Types
  • Basic
  • Collections
  • Structures
• Variables
  • Basic concepts
  • Predefined variables
  • Local and global variables
  • By value
  • By reference
• Constants (true, false, null, ...)
• Expressions and Statements
• Operators
  • Arithmetic
  • Relational
  • Conditional
• Control Structures (Statements)
  • Decisions
  • Loops
  • Exceptions
• Scripts and Functions
  • Scripts
  • Functions
  • Arguments
  • Internal functions
  • Returning values
  • Cache
• Stack
• Packages

New improvements have been planned for future launch.

• Quick operators about variables as:
  Copy

  <variable.dec name='a' />
  <variable.add name='a' value='1' />
  <variable.sub name='a' value='1' />
  <variable.sub name='a' value='${b}' />
  <variable.sub name='a' value='${b}' />
  <variable.mul />
  <variable.div />
  <variable.null name='a' />

• Use of EL expressions as:

          
  
  ${1 > (4/2)} false
  ${4.0 >= 3} true
  ${100.0 == 100} true
  ${(10*10) ne 100} false
  ${'a' < 'b'} true
  ${'hip' gt 'hit'} false
  ${4 > 3} true
  ${1.2E4 + 1.4} 12001.4
  ${3 div 4} 0.75
  ${10 mod 4} 2