Installing C XDK Components

The C XDK components are included with Oracle Database. This chapter assumes that you have installed XDK with Oracle Database and also installed the demo programs on the Oracle Database Companion CD. Refer to "Installing the XDK" for installation instructions and a description of the XDK directory structure.

Example 14-1 shows the UNIX directory structure for the XDK demos and the libraries used by the XDK components. The $ORACLE_HOME/xdk/demo/c subdirectories contain sample programs and data files for the XDK for C components. The chapters in Part II, "XDK for C" explain how to understand and use these programs.

The subdirectories contain sample programs and data files for the C XDK components. The chapters in Part II, "XDK for C" explain how to use these programs to gain an understanding of the most important C features.

Setting C XDK Environment Variables on UNIX

Table 14-2 describes the UNIX environment variables required for use with the XDK C components.

Table 14-2 UNIX Environment Settings for XDK C Components

Variable

Description

Setting

$ORA_NLS10

Sets the location of the Globalization Support character-encoding definition files. The encoding files represent a subset of character sets available in Oracle Database.

Set to the location of the Globalization Support data files. Set the variable as follows:

setenv ORA_NLS10 $ORACLE_HOME/nls/data

$ORA_XML_MESG

Sets the location of the XML error message files. Files ending in .msb are machine-readable and required at runtime. Files ending in .msg are human-readable and contain cause and action descriptions for each error.

Set to the path of the mesg directory. For example:

setenv ORA_XML_MESG $ORACLE_HOME/xdk/mesg

$PATH

Sets the location of the C XDK executables.

You can set the PATH as follows:

setenv PATH ${PATH}:${ORACLE_HOME}/bin

Testing the C XDK Runtime Environment on UNIX

You can test your UNIX runtime environment by running any of the utilities described in Table 14-3.

Run these utilities with no options to display the usage help. Run the utilities with the -hh flag for complete usage information.

Setting Up and Testing the C XDK Compile-Time Environment on UNIX

Table 14-4 describes the header files required for compilation of the C components. These files are located in $ORACLE_HOME/xdk/include. Note that your runtime environment must be set up before you can compile your code.

Table 14-4 Header Files in the C XDK Compile-Time Environment

Header File

Description

oratypes.h

Includes the private Oracle C datatypes.

oraxml.h

Includes the Oracle9i XML ORA datatypes and the public ORA APIs included in libxml.a (for backward compatibility only). Use xml.h instead.

oraxmlcg.h

Includes the C APIs for the C++ class generator (for backward compatibility only).

Handles the unified DOM APIs transparently, whether you use them through OCI or standalone. It replaces oraxml.h, which is deprecated.

xmlerr.h

Includes the XML errors and their numbers.

xmlotn.h

Includes the other headers depending on whether you compile standalone or use OCI.

xmlproc.h

Includes the Oracle 10g XML datatypes and XML public parser APIs in libxml10.a.

xmlsch.h

Includes the Oracle 10g XSD validator public APIs.

xmlptr.h

Includes the XPointer datatypes and APIs, which are not currently documented or supported.

xmlxsl.h

Includes the XSLT processor datatypes and public APIs.

xmlxvm.h

Includes the XSLT compiler and VM datatypes and public APIs.

Testing the C XDK Compile-Time Environment on UNIX

The simplest way to test your compile-time environment is to run the make utility on the sample programs, which are located on the Companion CD rather than on the Oracle Database 10g CD. After you install the demos, they will be located in $ORACLE_HOME/xdk/demo/c. A README in the same directory provides compilation instructions and usage notes.

Build and run the sample programs by executing the following commands at the system prompt:

cd $ORACLE_HOME/xdk/demo/c
make

Verifying the C XDK Component Version on UNIX

To obtain the version of XDK you are working with, change into $ORACLE_HOME/lib and run the following command:

Setting C XDK Environment Variables on Windows

Table 14-6 describes the Windows environment variables required for use with the XDK C components.

Table 14-6 Windows Environment Settings for C XDK Components

Variable

Description

Setting

%ORA_NLS10%

Sets the location of the Globalization Support character-encoding definition files. The encoding files represent a subset of character sets available in Oracle Database.

This variable should be set to the location of the Globalization Support data files. Set the variable as follows:

set ORA_NLS10=%ORACLE_HOME%\nls\data

%ORA_XML_MESG%

Sets the location of the XML error message files. Files ending in .msb are machine-readable and required at runtime. Files ending in .msg are human-readable and contain cause and action descriptions for each error.

Set to the path of the mesg directory. For example:

set ORA_XML_MESG=%ORACLE_HOME%\xdk\mesg

%PATH%

Sets the location of the C XDK DLLs and executables.

You can set the PATH as follows:

path %path%;%ORACLE_HOME%\bin

Testing the C XDK Runtime Environment on Windows

You can test your Windows runtime environment by running any of the utilities described in Table 14-7.

On Windows the header files are located in %ORACLE_HOME%\xdk\include. Note that you must set up your runtime environment before you can compile your code.

Testing the C XDK Compile-Time Environment on Windows

You can test your compile-time environment by compiling the demo programs, which are located in %ORACLE_HOME%\xdk\demo\c after you install them from the Oracle 10g Database Companion CD. A README in the same directory provides compilation instructions and usage notes.

Setting the C XDK Compiler Path on Windows

The demo make.bat file assumes that you are using the cl.exe compiler, which is freely available with the Microsoft .NET Framework Software Development Kit (SDK).

To set the path for the cl.exe compiler on Windows XP, follow these steps:

In the Start menu, select Settings and then Control Panel.

Double-click System.

In the System Properties dialogue box, select the Advanced tab and click Environment Variables.

In System variables, select Path and click Edit.

Append the path of cl.exe to the %PATH% variable as shown in Figure 14-1 and click OK.

Figure 14-1 Setting the Path for the C XDK Compiler and Linker on Windows

Editing the Make.bat Files on Windows

Each subfolder of the %ORACLE_HOME%\xdk\demo\c folder contains a Make.bat file. Update the Make.bat file in each folder by adding the path of the libraries and the header files to the compile command. You should not need to edit the paths in the :LINK section because /libpath:%ORACLE_HOME%\lib already points to the C libraries. The section of a Make.bat file in Example 14-1 uses bold text to show the path that you need to include.

After setting the paths for the static libraries in %ORACLE_HOME%\lib, set the library name in the compiling environment of Visual C++. Navigate to the Project menu in the menu bar and select Settings.

Select the Link tab in the Object/Library Modules field and enter the names of XDK C components libraries, as shown in the example in Figure 14-4.

Figure 14-4 Setting the Names of the Libraries in Visual C/C++ Project

Parse and manipulate XML documents with DOM. The API follows the DOM 2.0 standard as closely as possible, although it changes some names when mapping from the objected-oriented DOM specification to the flat C namespace. For example, the overloaded getName() methods become getAttrName().

The API accomplishes the unification of the functions by conforming contexts. A top-level XML context (xmlctx) shares common information between cooperating XML components. This context defines information such as the following:

Data encoding

Error message language

Low-level allocation callbacks

An application needs this information before it can parse a document and provide programmatic access through DOM or SAX.

Both the XDK and the Oracle XML DB required different startup and tear-down functions for the top-level and service contexts. The initialization function takes implementation-specific arguments and returns a conforming context. A conforming context means that the returned context must begin with a xmlctx; it may have any additional implementation-specific parts after the standard header.

Initialization, which is the acquisition of an xmlctx, is an implementation-specific step. After an application obtains xmlctx, it uses unified DOM calls, all of which take an xmlctx as the first argument.

The unified interface supersedes the C API in releases prior to Oracle Database 10g. In particular, the XDK has deprecated the oraxml interfaces (top-level, DOM, SAX and XSLT) and oraxsd (Schema) interfaces.

It is recommended that you use IANA character set names for interoperability with other XML parsers.

XML parsers are only required to support UTF-8 and UTF-16, so these character sets are preferable.

The default input encoding ("incoding") is UTF-8. If an input document's encoding is not self-evident (by HTTP character set, Byte Order Mark, XMLDecl, and so on), then the default input encoding is assumed. It is recommended that you set the default encoding explicitly if using only single byte character sets such as US-ASCII or any of the ISO-8859 character sets because single-byte performance is fastest. The flag XML_FLAG_FORCE_INCODING specifies that the default input encoding should always be applied to input documents, ignoring any BOM or XMLDecl. Nevertheless, a protocol declaration such as HTTP character set is always honored.

Choose the data encoding for DOM and SAX ("outcoding") carefully. Single-byte encodings are the fastest, but can represent only a very limited set of characters. Next fastest is Unicode (UTF-16), and slowest are the multibyte encodings such as UTF-8. If input data cannot be converted to the outcoding without loss, then an error occurs. For maximum utility, you should use a Unicode-based outcoding because Unicode can represent any character. If outcoding is not specified, then it defaults to the incoding of the first document parsed.

Scripting on this page enhances content navigation, but does not change the content in any way.