Generated C Function Format for XSD Types

---

Generated C pull-parser decode functions are written to a .c file with a name of the following format:

<xsdFileName>Dec.c

where <xsdFileName> is the base name of the XSD file being parsed. For example, if code is being generated for file x.xsd, decode functions for each type and global element defined in the specification will be written to xDec.c.

The format of the name of each generated XML decode function is as follows:

    [<ns>]XmlDT_<typeName>

where <typeName> is the name of the C type for which the function is being generated and <ns> is an optional namespace setting that can be used to disambiguate element names from multiple sources (note: this should not be confused with XML namespaces which are different).

The calling sequence for each decode function is as follows:

    stat = <decodeFunc> (OSCTXT* pctxt, <typeName>* pvalue);

In this definition, <decodeFunc> denotes the decode function name defined above.

The pctxt argument is used to hold a context pointer to keep track of decode parameters. This is a basic "handle" variable that is used to make the function reentrant so it can be used in an asynchronous or threaded application. The user is required to supply a pointer to a variable of this type declared somewhere in his or her program.

The pvalue argument is a pointer to a variable of the decode function type to receive the decoded data.

The function result variable stat returns the status of the decode operation. Status code 0 (zero) indicates the function was successful. A negative value indicates decoding failed. Return status values are defined in the rtxErrCodes.h include file. The error text and a stack trace can be displayed using the rtxErrPrint function.

A key difference between SAX-based functions and pull-parser based is that a decode function is not generated for all types in the SAX case. That is because of the overhead invlolved in setting up the SAX parser to decode simple types. Most simple types are decoded inline as part of more complex types. This is an example of a case where the pull-parser model more closely follows the encode model.