diff options
Diffstat (limited to 'xsd/doc')
| -rw-r--r-- | xsd/doc/.gitignore | 7 | ||||
| -rw-r--r-- | xsd/doc/buildfile | 372 | ||||
| -rw-r--r-- | xsd/doc/cxx/.gitignore | 4 | ||||
| -rw-r--r-- | xsd/doc/cxx/parser/guide/.gitignore | 2 | ||||
| -rw-r--r-- | xsd/doc/cxx/parser/guide/index.xhtml.in | 19 | ||||
| -rw-r--r-- | xsd/doc/cxx/tree/guide/.gitignore | 2 | ||||
| -rw-r--r-- | xsd/doc/cxx/tree/guide/index.xhtml.in | 14 | ||||
| -rw-r--r-- | xsd/doc/cxx/tree/manual/.gitignore | 2 | ||||
| -rw-r--r-- | xsd/doc/cxx/tree/manual/index.xhtml.in | 6 | ||||
| -rw-r--r-- | xsd/doc/pregenerated/xsd.1 | 1500 | ||||
| -rw-r--r-- | xsd/doc/pregenerated/xsd.xhtml | 1620 | ||||
| -rw-r--r-- | xsd/doc/xsd-epilogue.1 | 20 | ||||
| -rw-r--r-- | xsd/doc/xsd-epilogue.xhtml | 33 | ||||
| -rw-r--r-- | xsd/doc/xsd-prologue.xhtml | 5 |
14 files changed, 3422 insertions, 184 deletions
diff --git a/xsd/doc/.gitignore b/xsd/doc/.gitignore index 7ae560f..19b80b4 100644 --- a/xsd/doc/.gitignore +++ b/xsd/doc/.gitignore @@ -1,2 +1,5 @@ -xsd.1 -xsd.xhtml +/xsd.1 +/xsd.xhtml + +*.ps +*.pdf diff --git a/xsd/doc/buildfile b/xsd/doc/buildfile index ccfc060..271d17e 100644 --- a/xsd/doc/buildfile +++ b/xsd/doc/buildfile @@ -25,163 +25,271 @@ png{*}: extension = png define svg: file svg{*}: extension = svg -import? [metadata] cli = cli%exe{cli} +./: css{default} xsd{custom-literals} {png svg}{**} -# Import the html2ps and ps2pdf14 programs only if present on the system. This -# way a distribution that includes pre-generated files can be built without -# installing these programs. +# Note: doc_version is also used in the man pages and the manual. # -import? html2ps = html2ps%exe{html2ps} -import? ps2pdf14 = ps2pdf14%exe{ps2pdf14} +doc_version = [string] "$version.major.$version.minor.$version.patch" +if $version.pre_release + doc_version += "-$version.pre_release_string" -./: xsd{custom-literals} +# Man pages. +# -# Note that we include the cli, html2ps, and ps2pdf14 generated files into the -# distribution and don't remove them when cleaning in src (so that clean -# results in a state identical to distributed). +## Consumption build ($develop == false). +# -# Generate the man pages if the cli program is available and handle (install, -# distribute, etc) the pre-generated files otherwise, if present. +# Use pregenerated versions in the consumption build. +# +./: pregenerated/{man1 xhtml}{*}: include = (!$develop) + +# Distribute pregenerated versions only in the consumption build. +# +pregenerated/{man1 xhtml}{*}: dist = (!$develop) + +# +## + +## Development build ($develop == true). # -if ($cli != [null]) -{ - ./: {man1 xhtml}{xsd} - man_topics = $(src_root)/xsd/cxx/cli{options tree/options parser/options} +./: {man1 xhtml}{xsd}: include = $develop - man_options = -v project="XSD" \ - -v version="$version.project_id" \ - -v copyright="$copyright" \ - -I $src_root \ - --stdout \ - --suppress-undocumented \ +if $develop +{ + # Let's take the last four-digit number to cover 2000-2021,2022. + # + doc_year = $regex.replace($copyright, '.+[-, ]([0-9][0-9][0-9][0-9]) .+', '\1') + + man_options = -v project="XSD" \ + -v version="$doc_version" \ + -v copyright="$copyright" \ + -I $src_root \ + --stdout \ + --suppress-undocumented \ --exclude-base - man1{xsd}: $man_topics \ - man1{xsd-prologue \ - xsd-tree-header \ - xsd-parser-header \ - xsd-epilogue} \ - $cli - { - dist = true - clean = ($src_root != $out_root) - } - {{ - diag cli $> : ($<[0]) # @@ TMP: revise - - # Note that the date change doesn't change the script semantics, thus the - # variable is defined locally. - # - date +"%B %Y" | set date - - $cli --generate-man -v date="$date" $man_options \ - --class CXX::options \ - --class options \ - --man-prologue-file $path($<[3]) \ - $path($<[0]) >$path($>) - - $cli --generate-man -v date="$date" $man_options \ - --man-prologue-file $path($<[4]) \ - $path($<[1]) >>$path($>) - - $cli --generate-man -v date="$date" $man_options \ - --man-prologue-file $path($<[5]) \ - --man-epilogue-file $path($<[6]) \ - $path($<[2]) >>$path($>) - }} - - xhtml{xsd}: $man_topics \ - xhtml{xsd-prologue \ - xsd-tree-header \ - xsd-parser-header \ - xsd-epilogue} \ - css{*} \ - $cli + import! [metadata] cli = cli%exe{cli} +} + +# In the development build distribute regenerated versions, remapping their +# locations to the paths of the pregenerated versions (which are only +# distributed in the consumption build; see above). This way we make sure that +# the distributed files are always up-to-date. +# +{man1 xhtml}{xsd}: dist = ($develop ? pregenerated/ : false) + +ops = ../xsd/cli{options cxx/options cxx/tree/options cxx/parser/options} + +man1{xsd}: $ops \ + file{xsd-prologue.1 \ + xsd-tree-header.1 \ + xsd-parser-header.1 \ + xsd-epilogue.1} \ + $cli +% +if $develop +{{ + o = $path($>) + + # Use the copyright year to approximate the last authoring date. + # + $cli --generate-man $man_options \ + -v date="January $doc_year" \ + --class CXX::options \ + --class options \ + --man-prologue-file $path($<[4]) \ + $path($<[1]) >$o + + $cli --generate-man $man_options \ + -v date="January $doc_year" \ + --man-prologue-file $path($<[5]) \ + $path($<[2]) >>$o + + $cli --generate-man $man_options \ + -v date="January $doc_year" \ + --man-prologue-file $path($<[6]) \ + --man-epilogue-file $path($<[7]) \ + $path($<[3]) >>$o + + # If the result differs from the pregenerated version, copy it over. + # + if! diff $src_base/pregenerated/xsd.1 $o >- + cp $o $src_base/pregenerated/xsd.1 + end +}} + +xhtml{xsd}: $ops \ + file{xsd-prologue.xhtml \ + xsd-tree-header.xhtml \ + xsd-parser-header.xhtml \ + xsd-epilogue.xhtml} \ + $cli +% +if $develop +{{ + o = $path($>) + + $cli --generate-html $man_options \ + -v date="January $doc_year" \ + --class CXX::options \ + --class options \ + --html-prologue-file $path($<[4]) \ + $path($<[1]) >$o + + $cli --generate-html $man_options \ + -v date="January $doc_year" \ + --html-prologue-file $path($<[5]) \ + $path($<[2]) >>$o + + $cli --generate-html $man_options \ + -v date="January $doc_year" \ + --html-prologue-file $path($<[6]) \ + --html-epilogue-file $path($<[7]) \ + $path($<[3]) >>$o + + if! diff $src_base/pregenerated/xsd.xhtml $o >- + cp $o $src_base/pregenerated/xsd.xhtml + end +}} + +# +## + +# Manuals/guides. +# +# This case is slightly more involved because we make the generation of the +# manuals/guides ps/pdf files optional and also don't keep the result in the +# repository. Specifically: +# +# 1. In the consumption build we will install/redistribute ps/pdf if present. +# +# 2. In the development build we will generate ps/pdf if we are able to import +# the needed tools, issuing a warning otherwise. +# +# 3. We generate manuals/guides xhtml files from the templates and distribute +# them. + +manuals = cxx/parser/guide/index cxx/tree/guide/index cxx/tree/manual/index + +for m: $manuals +{ + ./: xhtml{$m}: in{$m} { + in.symbol = '@' + dist = true clean = ($src_root != $out_root) } - {{ - diag cli $> : ($<[0]) # @@ TMP: revise - - date +"%B %Y" | set date - - $cli --generate-html -v date="$date" $man_options \ - --class CXX::options \ - --class options \ - --html-prologue-file $path($<[3]) \ - $path($<[0]) >$path($>) - - $cli --generate-html -v date="$date" $man_options \ - --html-prologue-file $path($<[4]) \ - $path($<[1]) >>$path($>) - - $cli --generate-html -v date="$date" $man_options \ - --html-prologue-file $path($<[5]) \ - --html-epilogue-file $path($<[6]) \ - $path($<[2]) >>$path($>) - }} } -else - # Distribute both the pre-generated file (if present) and the sources. - # - ./: {man1 xhtml}{+xsd xsd-*} css{*} -# Generate the user guide/manual ps/pdf files if the html2ps and ps2pdf14 -# programs are imported and handle (install, distribute, etc) the -# pre-generated files otherwise, if present. +## Consumption build ($develop == false). +# + +# Use pregenerated versions, if exist, in the consumption build. +# +./: pregenerated/{ps pdf}{**}: include = (!$develop) + +# Distribute pregenerated versions only in the consumption build. +# +pregenerated/{ps pdf}{*}: dist = (!$develop) + +# +## + +## Development build ($develop == true). # -for d: cxx/parser/guide/ cxx/tree/guide/ cxx/tree/manual/ + +html2pdf = false + +if $develop { - p = "([dir_path] $path.leaf($path.directory($d)))" # parser, tree - l = "([dir_path] $path.leaf($d))" # guide, manual - f = "cxx-$p-$l" # cxx-parser-guide, etc + # Import the html2ps and ps2pdf programs from the system, if available. + # + import? html2ps = html2ps%exe{html2ps} + import? ps2pdf = ps2pdf14%exe{ps2pdf14} - ./: $d/xhtml{index}: $d/{png svg}{*} + html2pdf = ($html2ps != [null] && $ps2pdf != [null]) - $d/xhtml{index}: $d/in{index} - { - in.symbol = '@' - } + if! $html2pdf + warn "html2ps and/or ps2pdf14 are not available, not generating .ps and .pdf documentation" +} - if ($html2ps != [null]) - { - ./: $d/ps{$f}: $d/xhtml{index} $d/html2ps{$l} $html2ps - { - dist = true - clean = ($src_root != $out_root) - } - {{ - diag html2ps $> : ($<[0]) # @@ TMP: revise - - $html2ps -f $path($<[1]) -o $path($>) $path($<[0]) - }} - - if ($ps2pdf14 != [null]) - { - ./: $d/pdf{$f}: $d/ps{$f} $ps2pdf14 - { - dist = true - clean = ($src_root != $out_root) - } - {{ - diag ps2pdf14 $> : ($<[0]) # @@ TMP: revise - - $ps2pdf14 -dOptimize=true -dEmbedAllFonts=true $path($<[0]) $path($>) - }} - } - else - ./: $d/pdf{+$f} - } - else - ./: $d/{ps pdf}{+$f} $d/html2ps{$l} +for m: $manuals +{ + d = $directory($m) # cxx/parser/guide/, etc + p = "$leaf($directory($d))" # parser, tree + l = "$leaf($d)" # guide, manual + f = "cxx-$p-$l" # cxx-parser-guide, etc + + pf = $d/$f # cxx/parser/guide/cxx-parser-guide, etc + cf = $d/$l # cxx/parser/guide/guide, etc + + ./: {ps pdf}{$pf}: include = $html2pdf + + # In the development build distribute regenerated versions, remapping their + # locations to the paths of the pregenerated versions (which are only + # distributed in the consumption build; see above). This way we make sure + # that the distributed files are always up-to-date. + # + {ps pdf}{$pf}: \ + dist = ($html2pdf ? $relative([dir_path] "pregenerated/$d", $d) : false) + + pdf{$pf}: ps{$pf}: xhtml{$m} html2ps{$cf} - $d/html2ps{$l}: $d/in{$l} + html2ps{$cf}: in{$cf} { in.symbol = '@' } } -{man1 xhtml}{xsd-*}: install = false # xsd-prologue, etc +# Note: the pregenerated file may not exist, thus --no-cleanup option is +# required for the mkdir and cp builtin calls. Strictly speaking we don't +# really need to copy them since they are not stored in the repository, but +# let's do that for consistency with the distributed source tree. +# +ps{~'/cxx-.+-(.+)/'}: xhtml{~'/index/'} html2ps{~'/\1/'} $html2ps +% +if $html2pdf +{{ + # cxx/parser/guide/, etc + # + d = [dir_path] $leaf($directory($path($>[0])), $out_base) + + # Note: --base must include trailing directory separator. + # + options = --base $src_base/$d + + diag html2ps ($<[0]) -> $> + $html2ps $options -f $path($<[1]) -o $path($>) $path($<[0]) + + # Note: must include trailing directory separator (see cp for details). + # + d = $src_base/pregenerated/$d + + mkdir -p --no-cleanup $d + cp --no-cleanup $path($>) $d +}} + +pdf{~'/(cxx-.+-.+)/'}: ps{~'/\1/'} $ps2pdf +% +if $html2pdf +{{ + options = -dOptimize=true -dEmbedAllFonts=true + + diag ps2pdf ($<[0]) -> $> + $ps2pdf $options $path($<[0]) $path($>) + + # Note: must include trailing directory separator (see cp for details). + # + d = $src_base/pregenerated/$leaf($directory($path($>[0])), $out_base) + + mkdir -p --no-cleanup $d + cp --no-cleanup $path($>) $d +}} + +# +## + doc{*}: install.subdirs = true +pregenerated/doc{*}: install.subdirs = true diff --git a/xsd/doc/cxx/.gitignore b/xsd/doc/cxx/.gitignore index 239cc7f..45f6b1e 100644 --- a/xsd/doc/cxx/.gitignore +++ b/xsd/doc/cxx/.gitignore @@ -1,2 +1,2 @@ -*.ps -*.pdf +*.xhtml +*.html2ps diff --git a/xsd/doc/cxx/parser/guide/.gitignore b/xsd/doc/cxx/parser/guide/.gitignore deleted file mode 100644 index 17828e9..0000000 --- a/xsd/doc/cxx/parser/guide/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -index.xhtml -guide.html2ps diff --git a/xsd/doc/cxx/parser/guide/index.xhtml.in b/xsd/doc/cxx/parser/guide/index.xhtml.in index 96d06e2..119f421 100644 --- a/xsd/doc/cxx/parser/guide/index.xhtml.in +++ b/xsd/doc/cxx/parser/guide/index.xhtml.in @@ -553,7 +553,7 @@ </p> <pre class="terminal"> -$ xsd cxx-parser --std c++11 --xml-parser expat hello.xsd +$ xsd cxx-parser --xml-parser expat hello.xsd </pre> <p>The <code>--xml-parser</code> option indicates that we want to @@ -1494,7 +1494,7 @@ gender ::gender ::gender; option to let the XSD compiler know about our type map:</p> <pre class="terminal"> -$ xsd cxx-parser --std c++11 --type-map people.map people.xsd +$ xsd cxx-parser --type-map people.map people.xsd </pre> <p>If we now look at the generated <code>people-pskel.hxx</code>, @@ -1673,10 +1673,10 @@ namespace http://www.w3.org/2001/XMLSchema QName xml_schema::qname; - base64Binary std::[auto|unique]_ptr<xml_schema::buffer> - std::[auto|unique]_ptr<xml_schema::buffer>; - hexBinary std::[auto|unique]_ptr<xml_schema::buffer> - std::[auto|unique]_ptr<xml_schema::buffer>; + base64Binary std::[unique|auto]_ptr<xml_schema::buffer> + std::[unique|auto]_ptr<xml_schema::buffer>; + hexBinary std::[unique|auto]_ptr<xml_schema::buffer> + std::[unique|auto]_ptr<xml_schema::buffer>; date xml_schema::date; dateTime xml_schema::date_time; @@ -1742,8 +1742,7 @@ people ::people; recompile our schema and move on to implementing the parsers:</p> <pre class="terminal"> -$ xsd cxx-parser --std c++11 --xml-parser expat --type-map people.map \ - people.xsd +$ xsd cxx-parser --xml-parser expat --type-map people.map people.xsd </pre> <p>Here is the implementation of our three parsers in full. One @@ -2608,14 +2607,14 @@ private: <tr> <td><code>base64Binary</code></td> <td><code>base64_binary_pimpl</code></td> - <td><code>std::[auto|unique]_ptr< xml_schema::buffer></code><br/> + <td><code>std::[unique|auto]_ptr< xml_schema::buffer></code><br/> <a href="#6.3">Section 6.3, "<code>base64Binary</code> and <code>hexBinary</code> Parsers"</a></td> </tr> <tr> <td><code>hexBinary</code></td> <td><code>hex_binary_pimpl</code></td> - <td><code>std::[auto|unique]_ptr< xml_schema::buffer></code><br/> + <td><code>std::[unique|auto]_ptr< xml_schema::buffer></code><br/> <a href="#6.3">Section 6.3, "<code>base64Binary</code> and <code>hexBinary</code> Parsers"</a></td> </tr> diff --git a/xsd/doc/cxx/tree/guide/.gitignore b/xsd/doc/cxx/tree/guide/.gitignore deleted file mode 100644 index 17828e9..0000000 --- a/xsd/doc/cxx/tree/guide/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -index.xhtml -guide.html2ps diff --git a/xsd/doc/cxx/tree/guide/index.xhtml.in b/xsd/doc/cxx/tree/guide/index.xhtml.in index b704e50..2f7f1e2 100644 --- a/xsd/doc/cxx/tree/guide/index.xhtml.in +++ b/xsd/doc/cxx/tree/guide/index.xhtml.in @@ -536,7 +536,7 @@ </p> <pre class="terminal"> -$ xsd cxx-tree --std c++11 hello.xsd +$ xsd cxx-tree hello.xsd </pre> <p>The XSD compiler produces two C++ files: <code>hello.hxx</code> and @@ -633,7 +633,7 @@ hello (std::istream&); select C++98:</p> <pre class="terminal"> -$ xsd cxx-tree hello.xsd +$ xsd cxx-tree --std c++98 hello.xsd </pre> <p>Then the parsing function signatures will become:</p> @@ -726,7 +726,7 @@ Hello, world! it with the <code>--generate-serialization</code> options:</p> <pre class="terminal"> -$ xsd cxx-tree --std c++11 --generate-serialization hello.xsd +$ xsd cxx-tree --generate-serialization hello.xsd </pre> <p>If we now examine the generated <code>hello.hxx</code> file, @@ -911,7 +911,7 @@ main (int argc, char* argv[]) change the type naming scheme:</p> <pre class="terminal"> -$ xsd cxx-tree --std c++11 --type-naming ucc hello.xsd +$ xsd cxx-tree --type-naming ucc hello.xsd </pre> <p>The <code>ucc</code> argument to the <code>--type-naming</code> @@ -978,8 +978,7 @@ hello (std::istream&); <code>--type-regex</code> option:</p> <pre class="terminal"> -$ xsd cxx-tree --std c++11 --type-naming ucc \ - --type-regex '/ (.+)_t/\u$1/' hello.xsd +$ xsd cxx-tree --type-naming ucc --type-regex '/ (.+)_t/\u$1/' hello.xsd </pre> <p>This results in the following changes to the generated code:</p> @@ -1114,8 +1113,7 @@ hello (std::istream&); our schema with the <code>--generate-doxygen</code> option:</p> <pre class="terminal"> -$ xsd cxx-tree --std c++11 --generate-serialization --generate-doxygen \ - hello.xsd +$ xsd cxx-tree --generate-serialization --generate-doxygen hello.xsd </pre> <p>Now the generated <code>hello.hxx</code> file contains comments diff --git a/xsd/doc/cxx/tree/manual/.gitignore b/xsd/doc/cxx/tree/manual/.gitignore deleted file mode 100644 index 39e8d48..0000000 --- a/xsd/doc/cxx/tree/manual/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -index.xhtml -manual.html2ps diff --git a/xsd/doc/cxx/tree/manual/index.xhtml.in b/xsd/doc/cxx/tree/manual/index.xhtml.in index 5a7240a..5274229 100644 --- a/xsd/doc/cxx/tree/manual/index.xhtml.in +++ b/xsd/doc/cxx/tree/manual/index.xhtml.in @@ -8,7 +8,7 @@ <meta name="copyright" content="© @copyright@"/> <meta name="keywords" content="xsd,xml,schema,c++,mapping,data,binding,tree,serialization,guide,manual,examples"/> <meta name="description" content="C++/Tree Mapping User Manual"/> - <meta name="revision" content="4.1.0"/> + <meta name="revision" content="@doc_version@"/> <link rel="stylesheet" type="text/css" href="../../../default.css" /> @@ -441,9 +441,9 @@ called C++/Tree. </p> - <p>Revision 4.1.0<br/> <!-- Remember to change revision in other places --> + <p>Revision @doc_version@<br/> This revision of the manual describes the C++/Tree - mapping as implemented by CodeSynthesis XSD version 4.1.0. + mapping as implemented by CodeSynthesis XSD version @doc_version@. </p> <p>This document is available in the following formats: diff --git a/xsd/doc/pregenerated/xsd.1 b/xsd/doc/pregenerated/xsd.1 new file mode 100644 index 0000000..580ac78 --- /dev/null +++ b/xsd/doc/pregenerated/xsd.1 @@ -0,0 +1,1500 @@ +.\" Process this file with +.\" groff -man -Tascii xsd.1 +.\" +.TH XSD 1 "January 2023" "XSD 4.2.1-a.0" +.SH NAME +xsd \- W3C XML Schema to C++ Compiler +.\" +.\" +.\" +.\"-------------------------------------------------------------------- +.SH SYNOPSIS +.\"-------------------------------------------------------------------- +.B xsd +.I command +.B [ +.I options +.B ] +.I file +.B [ +.I file +.B ...] +.in +.B xsd help +.B [ +.I command +.B ] +.in +.B xsd version +.\" +.\" +.\" +.\"-------------------------------------------------------------------- +.SH DESCRIPTION +.\"-------------------------------------------------------------------- +.B xsd +generates vocabulary-specific, statically-typed C++ mapping from W3C XML +Schema definitions. Particular mapping to produce is selected by a +.IR command . +Each mapping has a number of mapping-specific +.I options +that should appear, if any, after the +.IR command . +Input files should be W3C XML Schema definitions. The exact set of the +generated files depends on the selected mapping and options. +.\" +.\" +.\" +.\"-------------------------------------------------------------------- +.SH COMMANDS +.\"-------------------------------------------------------------------- +.IP \fBcxx-tree\fR +Generate the C++/Tree mapping. For each input file in the form +.B name.xsd +the following C++ files are generated: +.B name.hxx +(header file), +.B name.ixx +(inline file, generated only if the +.B --generate-inline +option is specified), +.B name.cxx +(source file), and +.B name-fwd.hxx +(forward declaration file, generated only if the +.B --generate-forward +option is specified). + +.IP \fBcxx-parser\fR +Generate the C++/Parser mapping. For each input file in the form +.B name.xsd +the following C++ files are generated: +.B name-pskel.hxx +(parser skeleton header file), +.B name-pskel.ixx +(parser skeleton inline file, generated only if the +.B --generate-inline +option is specified), and +.B name-pskel.cxx +(parser skeleton source file). If the +.B --generate-noop-impl +or +.B --generate-print-impl +option is specified, the following additional sample implementation files +are generated: +.B name-pimpl.hxx +(parser implementation header file) and +.B name-pimpl.cxx +(parser implementation source file). If the +.B --generate-test-driver +option is specified, the additional +.B name-driver.cxx +test driver file is generated. + +.IP \fBhelp\fR +Print usage information and exit. Use +.PP +.RS +.RS 3 +.B xsd help +.I command +.RE +.PP +for command-specific help. +.RE +.IP \fBversion\fR +Print version and exit. +.\"-------------------------------------------------------------------- +.SH OPTIONS +.\"-------------------------------------------------------------------- +Command-specific +.IR options , +if any, should appear after the corresponding +.IR command . + +.\" +.\" Common options. +.\" +.SS common options +. +.IP "\fB--std\fR \fIversion\fR" +Specify the C++ standard that the generated code should conform to\. Valid +values are \fBc++98\fR, \fBc++11\fR (default), \fBc++14\fR, \fBc++17\fR, +\fBc++20\fR, and \fBc++23\fR\. + +The C++ standard affects various aspects of the generated code that are +discussed in more detail in various mapping-specific documentation\. Overall, +when C++11 is selected, the generated code relies on the move semantics and +uses \fBstd::unique_ptr\fR instead of deprecated \fBstd::auto_ptr\fR\. +Currently, there is no difference between the C++11 and the later standards +modes\. + +When the C++11 mode is selected, you normally don't need to perform any extra +steps other than enable C++11 in your C++ compiler, if required\. The XSD +compiler will automatically add the necessary macro defines to the generated +header files that will switch the header-only XSD runtime library +(\fBlibxsd\fR) to the C++11 mode\. However, if you include any of the XSD +runtime headers directly in your application (normally you just include the +generated headers), then you will need to define the \fBXSD_CXX11\fR macro for +your entire project\. +.IP "\fB--char-type\fR \fItype\fR" +Generate code using the provided character \fItype\fR instead of the default +\fBchar\fR\. Valid values are \fBchar\fR and \fBwchar_t\fR\. +.IP "\fB--char-encoding\fR \fIenc\fR" +Specify the character encoding that should be used in the generated code\. +Valid values for the \fBchar\fR character type are \fButf8\fR (default), +\fBiso8859-1\fR, \fBlcp\fR (Xerces-C++ local code page), and \fBcustom\fR\. If +you pass \fBcustom\fR as the value then you will need to include the +transcoder implementation header for your encoding at the beginning of the +generated header files (see the \fB--hxx-prologue\fR option)\. + +For the \fBwchar_t\fR character type the only valid value is \fBauto\fR and +the encoding is automatically selected between UTF-16 and UTF-32/UCS-4, +depending on the \fBwchar_t\fR type size\. +.IP "\fB--output-dir\fR \fIdir\fR" +Write generated files to \fIdir\fR instead of the current directory\. +.IP "\fB--generate-inline\fR" +Generate simple functions inline\. This option triggers creation of the inline +file\. +.IP "\fB--generate-xml-schema\fR" +Generate a C++ header file as if the schema being compiled defines the XML +Schema namespace\. For the C++/Tree mapping, the resulting file will contain +definitions for all XML Schema built-in types\. For the C++/Parser mapping, +the resulting file will contain definitions for all the parser skeletons and +implementations corresponding to the XML Schema built-in types\. + +The schema file provided to the compiler need not exist and is only used to +derive the name of the resulting header file\. Use the +\fB--extern-xml-schema\fR option to include this file in the generated files +for other schemas\. +.IP "\fB--extern-xml-schema\fR \fIfile\fR" +Include a header file derived from \fIfile\fR instead of generating the XML +Schema namespace mapping inline\. The provided file need not exist and is only +used to derive the name of the included header file\. Use the +\fB--generate-xml-schema\fR option to generate this header file\. +.IP "\fB--namespace-map\fR \fIxns\fR=\fIcns\fR" +Map XML Schema namespace \fIxns\fR to C++ namespace \fIcns\fR\. Repeat this +option to specify mapping for more than one XML Schema namespace\. For +example, the following option: + +\fB--namespace-map http://example\.com/foo/bar=foo::bar\fR + +Will map the \fBhttp://example\.com/foo/bar\fR XML Schema namespace to the +\fBfoo::bar\fR C++ namespace\. +.IP "\fB--namespace-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema namespace names to C++ namespace names\. \fIregex\fR is a Perl-like +regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. Any character can be +used as a delimiter instead of '\fB/\fR'\. Escaping of the delimiter character +in \fIpattern\fR or \fIreplacement\fR is not supported\. + +All the regular expressions are pushed into a stack with the last specified +expression considered first\. The first match that succeeds is used\. Regular +expressions are applied to a string in the form + +\fIfilename\fR \fInamespace\fR\fR + +For example, if you have file \fBhello\.xsd\fR with namespace +\fBhttp://example\.com/hello\fR and you run \fBxsd\fR on this file, then the +string in question will be: + +\fBhello\.xsd\. http://example\.com/hello\fR + +For the built-in XML Schema namespace the string is: + +\fBXMLSchema\.xsd http://www\.w3\.org/2001/XMLSchema\fR + +The following three steps are performed for each regular expression until the +match is found: + +1\. The expression is applied and if the result is empty the next expression +is considered\. + +2\. All '\fB/\fR' are replaced with '\fB::\fR'\. + +3\. The result is verified to be a valid C++ scope name (e\.g\., +\fBfoo::bar\fR)\. If this test succeeds, the result is used as a C++ namespace +name\. + +As an example, the following expression maps XML Schema namespaces in the +form \fBhttp://example\.com/foo/bar\fR to C++ namespaces in the form +\fBfoo::bar\fR: + +\fB%\.* http://example\.com/(\.+)%$1%\fR + +See also the REGEX AND SHELL QUOTING section below\. +.IP "\fB--namespace-regex-trace\fR" +Trace the process of applying regular expressions specified with the +\fB--namespace-regex\fR option\. Use this option to find out why your regular +expressions don't do what you expected them to do\. +.IP "\fB--reserved-name\fR \fIn\fR[=\fIr\fR]" +Add name \fIn\fR to the list of names that should not be used as identifiers\. +The name can optionally be followed by \fB=\fR and the replacement name +\fIr\fR that should be used instead\. All the C++ keywords are already in this +list\. +.IP "\fB--include-with-brackets\fR" +Use angle brackets (<>) instead of quotes ("") in generated \fB#include\fR +directives\. +.IP "\fB--include-prefix\fR \fIprefix\fR" +Add \fIprefix\fR to generated \fB#include\fR directive paths\. + +For example, if you had the following import element in your schema + +\fB<import namespace="\.\.\." schemaLocation="base\.xsd"/>\fR + +and compiled this fragment with \fB--include-prefix schemas/\fR, then the +include directive in the generated code would be: + +\fB#include "schemas/base\.hxx"\fR +.IP "\fB--include-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to transform +\fB#include\fR directive paths\. \fIregex\fR is a Perl-like regular expression +in the form \fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. Any +character can be used as a delimiter instead of '\fB/\fR'\. Escaping of the +delimiter character in \fIpattern\fR or \fIreplacement\fR is not supported\. + +All the regular expressions are pushed into a stack with the last specified +expression considered first\. The first match that succeeds is used\. + +As an example, the following expression transforms paths in the form +\fBschemas/foo/bar\fR to paths in the form \fBgenerated/foo/bar\fR: + +\fB%schemas/(\.+)%generated/$1%\fR + +See also the REGEX AND SHELL QUOTING section below\. +.IP "\fB--include-regex-trace\fR" +Trace the process of applying regular expressions specified with the +\fB--include-regex\fR option\. Use this option to find out why your regular +expressions don't do what you expected them to do\. +.IP "\fB--guard-prefix\fR \fIprefix\fR" +Add \fIprefix\fR to generated header inclusion guards\. The prefix is +transformed to upper case and characters that are illegal in a preprocessor +macro name are replaced with underscores\. If this option is not specified +then the directory part of the input schema file is used as a prefix\. +.IP "\fB--hxx-suffix\fR \fIsuffix\fR" +Use the provided \fIsuffix\fR instead of the default \fB\.hxx\fR to construct +the name of the header file\. Note that this suffix is also used to construct +names of header files corresponding to included/imported schemas\. +.IP "\fB--ixx-suffix\fR \fIsuffix\fR" +Use the provided \fIsuffix\fR instead of the default \fB\.ixx\fR to construct +the name of the inline file\. +.IP "\fB--cxx-suffix\fR \fIsuffix\fR" +Use the provided \fIsuffix\fR instead of the default \fB\.cxx\fR to construct +the name of the source file\. +.IP "\fB--fwd-suffix\fR \fIsuffix\fR" +Use the provided \fIsuffix\fR instead of the default \fB-fwd\.hxx\fR to +construct the name of the forward declaration file\. +.IP "\fB--hxx-regex\fR \fIregex\fR" +Use the provided expression to construct the name of the header file\. +\fIregex\fR is a Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. Note that this +expression is also used to construct names of header files corresponding to +included/imported schemas\. See also the REGEX AND SHELL QUOTING section +below\. +.IP "\fB--ixx-regex\fR \fIregex\fR" +Use the provided expression to construct the name of the inline file\. +\fIregex\fR is a Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. See also the REGEX +AND SHELL QUOTING section below\. +.IP "\fB--cxx-regex\fR \fIregex\fR" +Use the provided expression to construct the name of the source file\. +\fIregex\fR is a Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. See also the REGEX +AND SHELL QUOTING section below\. +.IP "\fB--fwd-regex\fR \fIregex\fR" +Use the provided expression to construct the name of the forward declaration +file\. \fIregex\fR is a Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. See also the REGEX +AND SHELL QUOTING section below\. +.IP "\fB--hxx-prologue\fR \fItext\fR" +Insert \fItext\fR at the beginning of the header file\. +.IP "\fB--ixx-prologue\fR \fItext\fR" +Insert \fItext\fR at the beginning of the inline file\. +.IP "\fB--cxx-prologue\fR \fItext\fR" +Insert \fItext\fR at the beginning of the source file\. +.IP "\fB--fwd-prologue\fR \fItext\fR" +Insert \fItext\fR at the beginning of the forward declaration file\. +.IP "\fB--prologue\fR \fItext\fR" +Insert \fItext\fR at the beginning of each generated file for which there is +no file-specific prologue\. +.IP "\fB--hxx-epilogue\fR \fItext\fR" +Insert \fItext\fR at the end of the header file\. +.IP "\fB--ixx-epilogue\fR \fItext\fR" +Insert \fItext\fR at the end of the inline file\. +.IP "\fB--cxx-epilogue\fR \fItext\fR" +Insert \fItext\fR at the end of the source file\. +.IP "\fB--fwd-epilogue\fR \fItext\fR" +Insert \fItext\fR at the end of the forward declaration file\. +.IP "\fB--epilogue\fR \fItext\fR" +Insert \fItext\fR at the end of each generated file for which there is no +file-specific epilogue\. +.IP "\fB--hxx-prologue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the beginning of the header file\. +.IP "\fB--ixx-prologue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the beginning of the inline file\. +.IP "\fB--cxx-prologue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the beginning of the source file\. +.IP "\fB--fwd-prologue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the beginning of the forward +declaration file\. +.IP "\fB--prologue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the beginning of each generated file +for which there is no file-specific prologue file\. +.IP "\fB--hxx-epilogue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the end of the header file\. +.IP "\fB--ixx-epilogue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the end of the inline file\. +.IP "\fB--cxx-epilogue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the end of the source file\. +.IP "\fB--fwd-epilogue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the end of the forward declaration +file\. +.IP "\fB--epilogue-file\fR \fIfile\fR" +Insert the content of the \fIfile\fR at the end of each generated file for +which there is no file-specific epilogue file\. +.IP "\fB--export-symbol\fR \fIsymbol\fR" +Insert \fIsymbol\fR in places where DLL export/import control statements +(\fB__declspec(dllexport/dllimport)\fR) are necessary\. +.IP "\fB--export-xml-schema\fR" +Export/import types in the XML Schema namespace using the export symbol +provided with the \fB--export-symbol\fR option\. The \fBXSD_NO_EXPORT\fR macro +can be used to omit this code during C++ compilation, which may be useful if +you would like to use the same generated code across multiple platforms\. +.IP "\fB--export-maps\fR" +Export polymorphism support maps from a Win32 DLL into which this generated +code is placed\. This is necessary when your type hierarchy is split across +several DLLs since otherwise each DLL will have its own set of maps\. In this +situation the generated code for the DLL which contains base types and/or +substitution group heads should be compiled with this option and the generated +code for all other DLLs should be compiled with \fB--import-maps\fR\. This +option is only valid together with \fB--generate-polymorphic\fR\. The +\fBXSD_NO_EXPORT\fR macro can be used to omit this code during C++ +compilation, which may be useful if you would like to use the same generated +code across multiple platforms\. +.IP "\fB--import-maps\fR" +Import polymorphism support maps to a Win32 DLL or executable into which this +generated code is linked\. See the \fB--export-maps\fR option documentation +for details\. This options is only valid together with +\fB--generate-polymorphic\fR\. The \fBXSD_NO_EXPORT\fR macro can be used to +omit this code during C++ compilation, which may be useful if you would like +to use the same generated code across multiple platforms\. +.IP "\fB--generate-dep\fR" +Generate \fBmake\fR dependency information\. This option triggers the creation +of the \fB\.d\fR file containing the dependencies of the generated files on +the main schema file as well as all the schema files that it includes/imports, +transitively\. This dependency file is then normally included into the main +\fBmakefile\fR to implement automatic dependency tracking\. See also the +\fB--dep-*\fR options\. + +Note also that automatic dependency generation is not supported in the +file-per-type mode (\fB--file-per-type\fR)\. In this case, all the generated +files are produced with a single compiler invocation and depend on all the +schemas\. As a result, it is easier to establish such a dependency manually, +perhaps with the help of the \fB--file-list*\fR options\. +.IP "\fB--generate-dep-only\fR" +Generate \fBmake\fR dependency information only\. +.IP "\fB--dep-phony\fR" +Generate phony targets for included/imported schema files, causing each to +depend on nothing\. Such dummy rules work around \fBmake\fR errors caused by +the removal of schema files without also updating the dependency file to +match\. +.IP "\fB--dep-target\fR \fItarget\fR" +Change the target of the dependency rule\. By default it contains all the +generated C++ files as well as the dependency file itself, without any +directory prefixes\. If you require multiple targets, then you can specify +them as a single, space-separated argument or you can repeat this option +multiple times\. +.IP "\fB--dep-suffix\fR \fIsuffix\fR" +Use \fIsuffix\fR instead of the default \fB\.d\fR to construct the name of the +dependency file\. See also \fB--dep-file\fR\. +.IP "\fB--dep-file\fR \fIpath\fR" +Use \fIpath\fR as the generated dependency file path instead of deriving it +from the input file name\. Write the dependency information to \fBstdout\fR if +\fIpath\fR is \fB-\fR\. See also \fB--dep-regex\fR\. +.IP "\fB--dep-regex\fR \fIregex\fR" +Use the provided expression to construct the name of the dependency file\. +\fIregex\fR is a Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. See also the REGEX +AND SHELL QUOTING section below\. +.IP "\fB--disable-warning\fR \fIwarn\fR" +Disable printing warning with id \fIwarn\fR\. If \fBall\fR is specified for +the warning id then all warnings are disabled\. +.IP "\fB--options-file\fR \fIfile\fR" +Read additional options from \fIfile\fR\. Each option should appearing on a +separate line optionally followed by space and an option value\. Empty lines +and lines starting with \fB#\fR are ignored\. Option values can be enclosed in +double (\fB"\fR) or single (\fB'\fR) quotes to preserve leading and trailing +whitespaces as well as to specify empty values\. If the value itself contains +trailing or leading quotes, enclose it with an extra pair of quotes, for +example \fB'"x"'\fR\. Non-leading and non-trailing quotes are interpreted as +being part of the option value\. + +The semantics of providing options in a file is equivalent to providing the +same set of options in the same order on the command line at the point where +the \fB--options-file\fR option is specified except that the shell escaping +and quoting is not required\. You can repeat this option to specify more than +one options file\. +.IP "\fB--show-sloc\fR" +Show the number of generated physical source lines of code (SLOC)\. +.IP "\fB--sloc-limit\fR \fInum\fR" +Check that the number of generated physical source lines of code (SLOC) does +not exceed \fInum\fR\. +.IP "\fB--proprietary-license\fR" +Indicate that the generated code is licensed under a proprietary license +instead of the GPL\. +.IP "\fB--custom-literals\fR \fIfile\fR" +Load custom XML string to C++ literal mappings from \fIfile\fR\. This +mechanism can be useful if you are using a custom character encoding and some +of the strings in your schemas, for example element/attribute names or +enumeration values, contain non-ASCII characters\. In this case you will need +to provide a custom mapping to C++ literals for such strings\. The format of +this file is specified in the \fBcustom-literals\.xsd\fR XML Schema file that +can be found in the documentation directory\. +.IP "\fB--preserve-anonymous\fR" +Preserve anonymous types\. By default anonymous types are automatically named +with names derived from the enclosing elements/attributes\. Because mappings +implemented by this compiler require all types to be named, this option is +only useful if you want to make sure your schemas don't have anonymous types\. +.IP "\fB--show-anonymous\fR" +Show elements and attributes that are of anonymous types\. This option only +makes sense together with the \fB--preserve-anonymous\fR option\. +.IP "\fB--anonymous-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to derive names for +anonymous types from the enclosing attributes/elements\. \fIregex\fR is a +Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. Any character can be +used as a delimiter instead of '\fB/\fR'\. Escaping of the delimiter character +in \fIpattern\fR or \fIreplacement\fR is not supported\. + +All the regular expressions are pushed into a stack with the last specified +expression considered first\. The first match that succeeds is used\. Regular +expressions are applied to a string in the form + +\fIfilename\fR \fInamespace\fR \fIxpath\fR\fR + +For instance: + +\fBhello\.xsd http://example\.com/hello element\fR + +\fBhello\.xsd http://example\.com/hello type/element\fR + +As an example, the following expression makes all the derived names start with +capital letters\. This could be useful when your naming convention requires +type names to start with capital letters: + +\fB%\.* \.* (\.+/)*(\.+)%\eu$2%\fR + +See also the REGEX AND SHELL QUOTING section below\. +.IP "\fB--anonymous-regex-trace\fR" +Trace the process of applying regular expressions specified with the +\fB--anonymous-regex\fR option\. Use this option to find out why your regular +expressions don't do what you expected them to do\. +.IP "\fB--location-map\fR \fIol\fR=\fInl\fR" +Map the original schema location \fIol\fR that is specified in the XML Schema +include or import elements to new schema location \fInl\fR\. Repeat this +option to map more than one schema location\. For example, the following +option maps the \fBhttp://example\.com/foo\.xsd\fR URL to the \fBfoo\.xsd\fR +local file\. + +\fB--location-map http://example\.com/foo\.xsd=foo\.xsd\fR +.IP "\fB--location-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to map schema +locations that are specified in the XML Schema include or import elements\. +\fIregex\fR is a Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. Any character can be +used as a delimiter instead of '\fB/\fR'\. Escaping of the delimiter character +in \fIpattern\fR or \fIreplacement\fR is not supported\. All the regular +expressions are pushed into a stack with the last specified expression +considered first\. The first match that succeeds is used\. + +For example, the following expression maps URL locations in the form +\fBhttp://example\.com/foo/bar\.xsd\fR to local files in the form +\fBbar\.xsd\fR: + +\fB%http://\.+/(\.+)%$1%\fR + +See also the REGEX AND SHELL QUOTING section below\. +.IP "\fB--location-regex-trace\fR" +Trace the process of applying regular expressions specified with the +\fB--location-regex\fR option\. Use this option to find out why your regular +expressions don't do what you expected them to do\. +.IP "\fB--file-per-type\fR" +Generate a separate set of C++ files for each type defined in XML Schema\. +Note that in this mode you only need to compile the root schema(s) and the +code will be generated for all included and imported schemas\. This +compilation mode is primarily useful when some of your schemas cannot be +compiled separately or have cyclic dependencies which involve type +inheritance\. Other options related to this mode are: \fB--type-file-regex\fR, +\fB--schema-file-regex\fR, \fB--fat-type-file\fR, and \fB--file-list\fR\. +.IP "\fB--type-file-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate type +names to file names when the \fB--file-per-type\fR option is specified\. +\fIregex\fR is a Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. Any character can be +used as a delimiter instead of '\fB/\fR'\. Escaping of the delimiter character +in \fIpattern\fR or \fIreplacement\fR is not supported\. All the regular +expressions are pushed into a stack with the last specified expression +considered first\. The first match that succeeds is used\. Regular expressions +are applied to a string in the form + +\fInamespace\fR \fItype-name\fR\fR + +For example, the following expression maps type \fBfoo\fR that is defined in +the \fBhttp://example\.com/bar\fR namespace to file name \fBbar-foo\fR: + +\fB%http://example\.com/(\.+) (\.+)%$1-$2%\fR + +See also the REGEX AND SHELL QUOTING section below\. +.IP "\fB--type-file-regex-trace\fR" +Trace the process of applying regular expressions specified with the +\fB--type-file-regex\fR option\. Use this option to find out why your regular +expressions don't do what you expected them to do\. +.IP "\fB--schema-file-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate schema +file names when the \fB--file-per-type\fR option is specified\. \fIregex\fR is +a Perl-like regular expression in the form +\fB/\fR\fIpattern\fR\fB/\fR\fIreplacement\fR\fB/\fR\fR\. Any character can be +used as a delimiter instead of '\fB/\fR'\. Escaping of the delimiter character +in \fIpattern\fR or \fIreplacement\fR is not supported\. All the regular +expressions are pushed into a stack with the last specified expression +considered first\. The first match that succeeds is used\. Regular Expressions +are applied to the absolute filesystem path of a schema file and the result, +including the directory part, if any, is used to derive the \fB#include\fR +directive paths as well as the generated C++ file paths\. This option, along +with \fB--type-file-regex\fR are primarily useful to place the generated files +into subdirectories or to resolve file name conflicts\. + +For example, the following expression maps schema files in the +\fBfoo/1\.0\.0/\fR subdirectory to the files in the \fBfoo/\fR subdirectory\. +As a result, the \fB#include\fR directive paths for such schemas will be in +the \fBfoo/schema\.hxx\fR form and the generated C++ files will be placed into +the \fBfoo/\fR subdirectory: + +\fB%\.*/foo/1\.0\.0/(\.+)%foo/$1%\fR + +See also the REGEX AND SHELL QUOTING section below\. +.IP "\fB--schema-file-regex-trace\fR" +Trace the process of applying regular expressions specified with the +\fB--schema-file-regex\fR option\. Use this option to find out why your +regular expressions don't do what you expected them to do\. +.IP "\fB--fat-type-file\fR" +Generate code corresponding to global elements into type files instead of +schema files when the \fB--type-file-regex\fR option is specified\. This +option is primarily useful when trying to minimize the amount of object code +that is linked to an executable by packaging compiled generated code into a +static (archive) library\. +.IP "\fB--file-list\fR \fIfile\fR" +Write a list of generated C++ files to \fIfile\fR or to \fBstdout\fR if +\fIfile\fR is \fB-\fR\. This option is primarily useful in the file-per-type +compilation mode (\fB--file-per-type\fR) to create a list of generated C++ +files, for example, as a makefile fragment\. +.IP "\fB--file-list-only\fR" +Only write the list of C++ files that would be generated without actually +generating them\. This option only makes sense together with +\fB--file-list\fR\. +.IP "\fB--file-list-prologue\fR \fItext\fR" +Insert \fItext\fR at the beginning of the file list\. As a convenience, all +occurrences of the \fB\en\fR character sequence in \fItext\fR are replaced +with new lines\. This option can, for example, be used to assign the generated +file list to a makefile variable\. +.IP "\fB--file-list-epilogue\fR \fItext\fR" +Insert \fItext\fR at the end of the file list\. As a convenience, all +occurrences of the \fB\en\fR character sequence in \fItext\fR are replaced +with new lines\. +.IP "\fB--file-list-delim\fR \fItext\fR" +Delimit file names written to the file list with \fItext\fR instead of new +lines\. As a convenience, all occurrences of the \fB\en\fR character sequence +in \fItext\fR are replaced with new lines\. +.\" +.\" C++/Tree options. +.\" +.SS cxx-tree command options +.IP "\fB--generate-polymorphic\fR" +Generate polymorphism-aware code\. Specify this option if you use substitution +groups or \fBxsi:type\fR\. Use the \fB--polymorphic-type\fR or +\fB--polymorphic-type-all\fR option to specify which type hierarchies are +polymorphic\. +.IP "\fB--polymorphic-type\fR \fItype\fR" +Indicate that \fItype\fR is a root of a polymorphic type hierarchy\. The +compiler can often automatically determine which types are polymorphic based +on the substitution group declarations\. However, you may need to use this +option if you are not using substitution groups or if substitution groups are +defined in another schema\. You need to specify this option when compiling +every schema file that references \fItype\fR\. The \fItype\fR argument is an +XML Schema type name that can be optionally qualified with a namespace in the +\fInamespace\fR\fB#\fR\fIname\fR\fR form\. +.IP "\fB--polymorphic-type-all\fR" +Indicate that all types should be treated as polymorphic\. +.IP "\fB--polymorphic-plate\fR \fInum\fR" +Specify the polymorphic map plate the generated code should register on\. This +functionality is primarily useful to segregate multiple schemas that define +the same polymorphic types\. +.IP "\fB--ordered-type\fR \fItype\fR" +Indicate that element order in \fItype\fR is significant\. An example would be +a complex type with unbounded choice as a content model where the element +order in XML has application-specific semantics\. For ordered types the +compiler generates a special container data member and a corresponding set of +accessors and modifiers that are used to capture the order of elements and, +for mixed content, of text\. + +The \fItype\fR argument is an XML Schema type name that can be optionally +qualified with a namespace in the \fInamespace\fR\fB#\fR\fIname\fR\fR form\. +Note also that you will need to specify this option when compiling every +schema file that has other ordered types derived from this type\. +.IP "\fB--ordered-type-derived\fR" +Automatically treat types derived from ordered bases as also ordered\. This is +primarily useful if you would like to be able to iterate over the complete +content using the content order container\. +.IP "\fB--ordered-type-mixed\fR" +Automatically treat complex types with mixed content as ordered\. +.IP "\fB--ordered-type-all\fR" +Indicate that element order in all types is significant\. +.IP "\fB--order-container\fR \fItype\fR" +Specify a custom class template that should be used as a container for the +content order in ordered types instead of the default \fBstd::vector\fR\. See +\fB--ordered-type\fR for more information on ordered type\. This option is +primarily useful if you need to perform more complex lookups in the content +order container, for example by element id\. In this case, a container like +Boost multi-index may be more convenient\. Note that if using a custom +container, you will also most likely need to include the relevant headers +using the \fB--hxx-prologue*\fR options\. +.IP "\fB--generate-serialization\fR" +Generate serialization functions\. Serialization functions convert the object +model back to XML\. +.IP "\fB--generate-ostream\fR" +Generate ostream insertion operators (\fBoperator<<\fR) for generated types\. +This allows one to easily print a fragment or the whole object model for +debugging or logging\. +.IP "\fB--generate-doxygen\fR" +Generate documentation comments suitable for extraction by the Doxygen +documentation system\. Documentation from annotations is added to the comments +if present in the schema\. +.IP "\fB--generate-comparison\fR" +Generate comparison operators (\fBoperator==\fR and \fBoperator!=\fR) for +complex types\. Comparison is performed member-wise\. +.IP "\fB--generate-default-ctor\fR" +Generate default constructors even for types that have required members\. +Required members of an instance constructed using such a constructor are not +initialized and accessing them results in undefined behavior\. +.IP "\fB--generate-from-base-ctor\fR" +Generate constructors that expect an instance of a base type followed by all +required members\. +.IP "\fB--suppress-assignment\fR" +Suppress the generation of copy assignment operators for complex types\. If +this option is specified, the copy assignment operators for such types are +declared private and left unimplemented\. +.IP "\fB--generate-detach\fR" +Generate detach functions for required elements and attributes\. Detach +functions for optional and sequence cardinalities are provided by the +respective containers\. These functions, for example, allow you to move +sub-trees in the object model either within the same tree or between different +trees\. +.IP "\fB--generate-wildcard\fR" +Generate accessors and modifiers as well as parsing and serialization code for +XML Schema wildcards (\fBany\fR and \fBanyAttribute\fR)\. XML content matched +by wildcards is presented as DOM fragments\. Note that you need to initialize +the Xerces-C++ runtime if you are using this option\. +.IP "\fB--generate-any-type\fR" +Extract and store content of the XML Schema \fBanyType\fR type as a DOM +fragment\. Note that you need to initialize the Xerces-C++ runtime if you are +using this option\. +.IP "\fB--generate-insertion\fR \fIos\fR" +Generate data representation stream insertion operators for the \fIos\fR +output stream type\. Repeat this option to specify more than one stream type\. +The ACE CDR stream (\fBACE_OutputCDR\fR) and RPC XDR are recognized by the +compiler and the necessary \fB#include\fR directives are automatically +generated\. For custom stream types use the \fB--hxx-prologue*\fR options to +provide the necessary declarations\. +.IP "\fB--generate-extraction\fR \fIis\fR" +Generate data representation stream extraction constructors for the \fIis\fR +input stream type\. Repeat this option to specify more than one stream type\. +The ACE CDR stream (\fBACE_InputCDR\fR) and RPC XDR are recognized by the +compiler and the necessary \fB#include\fR directives are automatically +generated\. For custom stream types use the \fB--hxx-prologue*\fR options to +provide the necessary declarations\. +.IP "\fB--generate-forward\fR" +Generate a separate header file with forward declarations for the types being +generated\. +.IP "\fB--suppress-parsing\fR" +Suppress the generation of the parsing functions and constructors\. Use this +option to reduce the generated code size when parsing from XML is not needed\. +.IP "\fB--generate-element-type\fR" +Generate types instead of parsing and serialization functions for root +elements\. This is primarily useful to distinguish object models with the same +root type but with different root elements\. +.IP "\fB--generate-element-map\fR" +Generate a root element map that allows uniform parsing and serialization of +multiple root elements\. This option is only valid together with +\fB--generate-element-type\fR\. +.IP "\fB--generate-intellisense\fR" +Generate workarounds for IntelliSense bugs in Visual Studio 2005 (8\.0)\. When +this option is used, the resulting code is slightly more verbose\. +IntelliSense in Visual Studio 2008 (9\.0) and later does not require these +workarounds\. Support for IntelliSense in Visual Studio 2003 (7\.1) is +improved with this option but is still incomplete\. +.IP "\fB--omit-default-attributes\fR" +Omit attributes with default and fixed values from serialized XML documents\. +.IP "\fB--type-naming\fR \fIstyle\fR" +Specify the type naming convention that should be used in the generated code\. +Valid styles are \fBknr\fR (default), \fBucc\fR, and \fBjava\fR\. See the +NAMING CONVENTION section below for more information\. +.IP "\fB--function-naming\fR \fIstyle\fR" +Specify the function naming convention that should be used in the generated +code\. Valid styles are \fBknr\fR (default), \fBlcc\fR, \fBucc\fR, and +\fBjava\fR\. See the NAMING CONVENTION section below for more information\. +.IP "\fB--type-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema type names to C++ type names\. See the NAMING CONVENTION section below +for more information\. +.IP "\fB--accessor-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema names of elements/attributes to C++ accessor function names\. See the +NAMING CONVENTION section below for more information\. +.IP "\fB--one-accessor-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema names of elements/attributes with cardinality one to C++ accessor +function names\. See the NAMING CONVENTION section below for more +information\. +.IP "\fB--opt-accessor-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema names of elements/attributes with cardinality optional to C++ accessor +function names\. See the NAMING CONVENTION section below for more +information\. +.IP "\fB--seq-accessor-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema names of elements/attributes with cardinality sequence to C++ accessor +function names\. See the NAMING CONVENTION section below for more +information\. +.IP "\fB--modifier-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema names of elements/attributes to C++ modifier function names\. See the +NAMING CONVENTION section below for more information\. +.IP "\fB--one-modifier-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema names of elements/attributes with cardinality one to C++ modifier +function names\. See the NAMING CONVENTION section below for more +information\. +.IP "\fB--opt-modifier-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema names of elements/attributes with cardinality optional to C++ modifier +function names\. See the NAMING CONVENTION section below for more +information\. +.IP "\fB--seq-modifier-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema names of elements/attributes with cardinality sequence to C++ modifier +function names\. See the NAMING CONVENTION section below for more +information\. +.IP "\fB--parser-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema element names to C++ parsing function names\. See the NAMING CONVENTION +section below for more information\. +.IP "\fB--serializer-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema element names to C++ serialization function names\. See the NAMING +CONVENTION section below for more information\. +.IP "\fB--const-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema-derived names to C++ constant names\. See the NAMING CONVENTION section +below for more information\. +.IP "\fB--enumerator-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema enumeration values to C++ enumerator names\. See the NAMING CONVENTION +section below for more information\. +.IP "\fB--element-type-regex\fR \fIregex\fR" +Add \fIregex\fR to the list of regular expressions used to translate XML +Schema element names to C++ element type names\. See the NAMING CONVENTION +section below for more information\. +.IP "\fB--name-regex-trace\fR" +Trace the process of applying regular expressions specified with the name +transformation options\. Use this option to find out why your regular +expressions don't do what you expected them to do\. +.IP "\fB--root-element-first\fR" +Treat only the first global element as a document root\. By default all global +elements are considered document roots\. +.IP "\fB--root-element-last\fR" +Treat only the last global element as a document root\. By default all global +elements are considered document roots\. +.IP "\fB--root-element-all\fR" +Treat all global elements as document roots\. This is the default behavior\. +By explicitly specifying this option you can suppress the warning that is +issued if more than one global element is defined\. +.IP "\fB--root-element-none\fR" +Do not treat any global elements as document roots\. By default all global +elements are considered document roots\. +.IP "\fB--root-element\fR \fIelement\fR" +Treat only \fIelement\fR as a document root\. Repeat this option to specify +more than one root element\. +.IP "\fB--custom-type\fR \fImap\fR" +Use a custom C++ type instead of the generated class\. The \fImap\fR argument +is in the form \fIname\fR[\fB=\fR\fItype\fR[\fB/\fR\fIbase\fR]]\fR, where +\fIname\fR is a type name as defined in XML Schema and \fItype\fR is a C++ +type name that should be used instead\. If \fItype\fR is not present or empty +then the custom type is assumed to have the same name and be defined in the +same namespace as the generated class would have\. If \fIbase\fR is specified +then the generated class is still generated but with that name\. +.IP "\fB--custom-type-regex\fR \fIregex\fR" +Use custom C++ types instead of the generated classes\. The \fIregex\fR +argument is in the form +\fB/\fR\fIname-pat\fR\fB/\fR[\fItype-sub\fR\fB/\fR[\fIbase-sub\fR\fB/\fR]]\fR, +where \fIname-pat\fR is a regex pattern that will be matched against type +names as defined in XML Schema and \fItype-sub\fR is a C++ type name +substitution that should be used instead\. If \fItype-sub\fR is not present or +its substitution results in an empty string then the custom type is assumed to +have the same name and be defined in the same namespace as the generated class +would have\. If \fIbase-sub\fR is present and its substitution results in a +non-empty string then the generated class is still generated but with the +result of this substitution as its name\. The pattern and substitutions are in +the Perl regular expression format\. See also the REGEX AND SHELL QUOTING +section below\. +.IP "\fB--parts\fR \fInum\fR" +Split generated source code into \fInum\fR parts\. This is useful when +translating large, monolithic schemas and a C++ compiler is not able to +compile the resulting source code at once (usually due to insufficient +memory)\. +.IP "\fB--parts-suffix\fR \fIsuffix\fR" +Use \fIsuffix\fR instead of the default '\fB-\fR' to separate the file name +from the part number\. +\" +\" C++/Parser +\" +.SS cxx-parser command options +.IP "\fB--type-map\fR \fImapfile\fR" +Read XML Schema to C++ type mapping information from \fImapfile\fR\. Repeat +this option to specify several type maps\. Type maps are considered in order +of appearance and the first match is used\. By default all user-defined types +are mapped to \fBvoid\fR\. See the TYPE MAP section below for more +information\. +.IP "\fB--xml-parser\fR \fIparser\fR" +Use \fIparser\fR as the underlying XML parser\. Valid values are \fBxerces\fR +for Xerces-C++ (default) and \fBexpat\fR for Expat\. +.IP "\fB--generate-validation\fR" +Generate validation code\. The validation code ("perfect parser") ensures that +instance documents conform to the schema\. Validation code is generated by +default when the selected underlying XML parser is non-validating +(\fBexpat\fR)\. +.IP "\fB--suppress-validation\fR" +Suppress the generation of validation code\. Validation is suppressed by +default when the selected underlying XML parser is validating (\fBxerces\fR)\. +.IP "\fB--generate-polymorphic\fR" +Generate polymorphism-aware code\. Specify this option if you use substitution +groups or \fBxsi:type\fR\. +.IP "\fB--generate-noop-impl\fR" +Generate a sample parser implementation that does nothing (no operation)\. The +sample implementation can then be filled with the application-specific code\. +For an input file in the form \fBname\.xsd\fR this option triggers the +generation of two additional C++ files in the form: \fBname-pimpl\.hxx\fR +(parser implementation header file) and \fBname-pimpl\.cxx\fR (parser +implementation source file)\. +.IP "\fB--generate-print-impl\fR" +Generate a sample parser implementation that prints the XML data to +STDOUT\fR\. For an input file in the form \fBname\.xsd\fR this option triggers +the generation of two additional C++ files in the form: \fBname-pimpl\.hxx\fR +(parser implementation header file) and \fBname-pimpl\.cxx\fR (parser +implementation source file)\. +.IP "\fB--generate-test-driver\fR" +Generate a test driver for the sample parser implementation\. For an input +file in the form \fBname\.xsd\fR this option triggers the generation of an +additional C++ file in the form \fBname-driver\.cxx\fR\. +.IP "\fB--force-overwrite\fR" +Force overwriting of the existing implementation and test driver files\. Use +this option only if you do not mind loosing the changes you have made in the +sample implementation or test driver files\. +.IP "\fB--root-element-first\fR" +Indicate that the first global element is the document root\. This information +is used to generate the test driver for the sample implementation\. +.IP "\fB--root-element-last\fR" +Indicate that the last global element is the document root\. This information +is used to generate the test driver for the sample implementation\. +.IP "\fB--root-element\fR \fIelement\fR" +Indicate that \fIelement\fR is the document root\. This information is used to +generate the test driver for the sample implementation\. +.IP "\fB--skel-type-suffix\fR \fIsuffix\fR" +Use the provided \fIsuffix\fR instead of the default \fB_pskel\fR to construct +the names of the generated parser skeletons\. +.IP "\fB--skel-file-suffix\fR \fIsuffix\fR" +Use the provided \fIsuffix\fR instead of the default \fB-pskel\fR to construct +the names of the generated parser skeleton files\. +.IP "\fB--impl-type-suffix\fR \fIsuffix\fR" +Use the provided \fIsuffix\fR instead of the default \fB_pimpl\fR to construct +the names of the parser implementations for the built-in XML Schema types as +well as sample parser implementations\. +.IP "\fB--impl-file-suffix\fR \fIsuffix\fR" +Use the provided \fIsuffix\fR instead of the default \fB-pimpl\fR to construct +the names of the generated sample parser implementation files\. +\" +\" NAMING CONVENTION +\" + +.SH NAMING CONVENTION +The compiler can be instructed to use a particular naming convention in +the generated code. A number of widely-used conventions can be selected +using the +.B --type-naming +and +.B --function-naming +options. A custom naming convention can be achieved using the +.BR --type-regex , +.BR --accessor-regex , +.BR --one-accessor-regex , +.BR --opt-accessor-regex , +.BR --seq-accessor-regex , +.BR --modifier-regex , +.BR --one-modifier-regex , +.BR --opt-modifier-regex , +.BR --seq-modifier-regex , +.BR --parser-regex , +.BR --serializer-regex , +.BR --const-regex , +.BR --enumerator-regex , +and +.B --element-type-regex +options. + +The +.B --type-naming +option specifies the convention that should be used for naming C++ types. +Possible values for this option are +.B knr +(default), +.BR ucc , +and +.BR java . +The +.B knr +value (stands for K&R) signifies the standard, lower-case naming convention +with the underscore used as a word delimiter, for example: foo, foo_bar. +The +.B ucc +(stands for upper-camel-case) and +.B java +values a synonyms for the same naming convention where the first letter +of each word in the name is capitalized, for example: Foo, FooBar. + +Similarly, the +.B --function-naming +option specifies the convention that should be used for naming C++ functions. +Possible values for this option are +.B knr +(default), +.BR lcc , +and +.BR java . +The +.B knr +value (stands for K&R) signifies the standard, lower-case naming convention +with the underscore used as a word delimiter, for example: foo(), foo_bar(). +The +.B lcc +value (stands for lower-camel-case) signifies a naming convention where the +first letter of each word except the first is capitalized, for example: foo(), +fooBar(). The +.B ucc +value (stands for upper-camel-case) signifies a naming convention where the +first letter of each word is capitalized, for example: Foo(), FooBar(). The +.B java +naming convention is similar to the lower-camel-case one except that accessor +functions are prefixed with get, modifier functions are prefixed with set, +parsing functions are prefixed with parse, and serialization functions are +prefixed with serialize, for example: getFoo(), setFooBar(), parseRoot(), +serializeRoot(). + +Note that the naming conventions specified with the +.B --type-naming +and +.B --function-naming +options perform only limited transformations on the +names that come from the schema in the form of type, attribute, and element +names. In other words, to get consistent results, your schemas should follow +a similar naming convention as the one you would like to have in the generated +code. Alternatively, you can use the +.B --*-regex +options (discussed below) to perform further transformations on the names +that come from the schema. + +The +.BR --type-regex , +.BR --accessor-regex , +.BR --one-accessor-regex , +.BR --opt-accessor-regex , +.BR --seq-accessor-regex , +.BR --modifier-regex , +.BR --one-modifier-regex , +.BR --opt-modifier-regex , +.BR --seq-modifier-regex , +.BR --parser-regex , +.BR --serializer-regex , +.BR --const-regex , +.BR --enumerator-regex , +and +.B --element-type-regex +options allow you to specify extra regular expressions for each name +category in addition to the predefined set that is added depending on +the +.B --type-naming +and +.B --function-naming +options. Expressions that are provided with the +.B --*-regex +options are evaluated prior to any predefined expressions. This allows +you to selectively override some or all of the predefined transformations. +When debugging your own expressions, it is often useful to see which +expressions match which names. The +.B --name-regex-trace +option allows you to trace the process of applying +regular expressions to names. + +The value for the +.B --*-regex +options should be a perl-like regular expression in the form +.BI / pattern / replacement /\fR. +Any character can be used as a delimiter instead of +.BR / . +Escaping of the delimiter character in +.I pattern +or +.I replacement +is not supported. All the regular expressions for each category are pushed +into a category-specific stack with the last specified expression +considered first. The first match that succeeds is used. For the +.B --one-accessor-regex +(accessors with cardinality one), +.B --opt-accessor-regex +(accessors with cardinality optional), and +.B --seq-accessor-regex +(accessors with cardinality sequence) categories the +.B --accessor-regex +expressions are used as a fallback. For the +.BR --one-modifier-regex , +.BR --opt-modifier-regex , +and +.B --seq-modifier-regex +categories the +.B --modifier-regex +expressions are used as a fallback. For the +.B --element-type-regex +category the +.B --type-regex +expressions are used as a fallback. + +The type name expressions +.RB ( --type-regex ) +are evaluated on the name string that has the following format: + +[\fInamespace \fR]\fIname\fR[\fB,\fIname\fR][\fB,\fIname\fR][\fB,\fIname\fR] + +The element type name expressions +.RB ( --element-type-regex ), +effective only when the +.B --generate-element-type +option is specified, are evaluated on the name string that has the following +format: + +.I namespace name + +In the type name format the +.I namespace +part followed by a space is only present for global type names. For global +types and elements defined in schemas without a target namespace, the +.I namespace +part is empty but the space is still present. In the type name format after +the initial +.I name +component, up to three additional +.I name +components can be present, separated by commas. For example: + +.B http://example.com/hello type + +.B foo + +.B foo,iterator + +.B foo,const,iterator + +The following set of predefined regular expressions is used to transform +type names when the upper-camel-case naming convention is selected: + +.B /(?:[^ ]* )?([^,]+)/\\\\u$1/ + +.B /(?:[^ ]* )?([^,]+),([^,]+)/\\\\u$1\\\\u$2/ + +.B /(?:[^ ]* )?([^,]+),([^,]+),([^,]+)/\\\\u$1\\\\u$2\\\\u$3/ + +.B /(?:[^ ]* )?([^,]+),([^,]+),([^,]+),([^,]+)/\\\\u$1\\\\u$2\\\\u$3\\\\u$4/ + +The accessor and modifier expressions +.RB ( --*accessor-regex +and +.BR --*modifier-regex ) +are evaluated on the name string that has the following format: + +\fIname\fR[\fB,\fIname\fR][\fB,\fIname\fR] + +After the initial +.I name +component, up to two additional +.I name +components can be present, separated by commas. For example: + +.B foo + +.B dom,document + +.B foo,default,value + +The following set of predefined regular expressions is used to transform +accessor names when the +.B java +naming convention is selected: + +.B /([^,]+)/get\\\\u$1/ + +.B /([^,]+),([^,]+)/get\\\\u$1\\\\u$2/ + +.B /([^,]+),([^,]+),([^,]+)/get\\\\u$1\\\\u$2\\\\u$3/ + +For the parser, serializer, and enumerator categories, the corresponding +regular expressions are evaluated on local names of elements and on +enumeration values, respectively. For example, the following predefined +regular expression is used to transform parsing function names when the +.B java +naming convention is selected: + +.B /(.+)/parse\\\\u$1/ + +The const category is used to create C++ constant names for the +element/wildcard/text content ids in ordered types. + +See also the REGEX AND SHELL QUOTING section below. + +\" +\" TYPE MAP +\" +.SH TYPE MAP +Type map files are used in C++/Parser to define a mapping between XML +Schema and C++ types. The compiler uses this information to determine +the return types of +.B post_* +functions in parser skeletons corresponding to XML Schema types +as well as argument types for callbacks corresponding to elements +and attributes of these types. + +The compiler has a set of predefined mapping rules that map built-in +XML Schema types to suitable C++ types (discussed below) and all +other types to +.BR void . +By providing your own type maps you can override these predefined rules. +The format of the type map file is presented below: + +.RS +.B namespace +.I schema-namespace +[ +.I cxx-namespace +] +.br +.B { +.br + ( +.B include +.IB file-name ; +)* +.br + ([ +.B type +] +.I schema-type cxx-ret-type +[ +.I cxx-arg-type +.RB ] ; +)* +.br +.B } +.br +.RE + +Both +.I schema-namespace +and +.I schema-type +are regex patterns while +.IR cxx-namespace , +.IR cxx-ret-type , +and +.I cxx-arg-type +are regex pattern substitutions. All names can be optionally enclosed +in \fR" "\fR, for example, to include white-spaces. + +.I schema-namespace +determines XML Schema namespace. Optional +.I cxx-namespace +is prefixed to every C++ type name in this namespace declaration. +.I cxx-ret-type +is a C++ type name that is used as a return type for the +.B post_* +functions. Optional +.I cxx-arg-type +is an argument type for callback functions corresponding to elements and +attributes of this type. If +.I cxx-arg-type +is not specified, it defaults to +.I cxx-ret-type +if +.I cxx-ret-type +ends with +.B * +or +.B & +(that is, it is a pointer or a reference) and +.B const +\fIcxx-ret-type\fB&\fR otherwise. +.I file-name +is a file name either in the \fR" "\fR or < > format and is added with the +.B #include +directive to the generated code. + +The \fB#\fR character starts a comment that ends with a new line or end of +file. To specify a name that contains \fB#\fR enclose it in \fR" "\fR. For +example: + +.RS +namespace http://www.example.com/xmlns/my my +.br +{ +.br + include "my.hxx"; +.br + + # Pass apples by value. + # + apple apple; +.br + + # Pass oranges as pointers. + # + orange orange_t*; +.br +} +.br +.RE + +In the example above, for the +.B http://www.example.com/xmlns/my#orange +XML Schema type, the +.B my::orange_t* +C++ type will be used as both return and argument types. + +Several namespace declarations can be specified in a single file. +The namespace declaration can also be completely omitted to map +types in a schema without a namespace. For instance: + +.RS +include "my.hxx"; +.br +apple apple; +.br + +namespace http://www.example.com/xmlns/my +.br +{ +.br + orange "const orange_t*"; +.br +} +.br +.RE + +The compiler has a number of predefined mapping rules that can be +presented as the following map files. The string-based XML Schema +built-in types are mapped to either +.B std::string +or +.B std::wstring +depending on the character type selected with the +.B --char-type +option +.RB ( char +by default). The binary XML Schema types are mapped to either +.B std::unique_ptr<xml_schema::buffer> +or +.B std::auto_ptr<xml_schema::buffer> +depending on the C++ standard selected with the +.B --std +option +.RB ( c++11 +by default). + +.RS +namespace http://www.w3.org/2001/XMLSchema +.br +{ +.br + boolean bool bool; +.br + + byte "signed char" "signed char"; +.br + unsignedByte "unsigned char" "unsigned char"; +.br + + short short short; +.br + unsignedShort "unsigned short" "unsigned short"; +.br + + int int int; +.br + unsignedInt "unsigned int" "unsigned int"; +.br + + long "long long" "long long"; +.br + unsignedLong "unsigned long long" "unsigned long long"; +.br + + integer "long long" "long long"; +.br + + negativeInteger "long long" "long long"; +.br + nonPositiveInteger "long long" "long long"; +.br + + positiveInteger "unsigned long long" "unsigned long long"; +.br + nonNegativeInteger "unsigned long long" "unsigned long long"; +.br + + float float float; +.br + double double double; +.br + decimal double double; +.br + + string std::string; +.br + normalizedString std::string; +.br + token std::string; +.br + Name std::string; +.br + NMTOKEN std::string; +.br + NCName std::string; +.br + ID std::string; +.br + IDREF std::string; +.br + language std::string; +.br + anyURI std::string; +.br + + NMTOKENS xml_schema::string_sequence; +.br + IDREFS xml_schema::string_sequence; +.br + + QName xml_schema::qname; +.br + + base64Binary std::[unique|auto]_ptr<xml_schema::buffer> +.br + std::[unique|auto]_ptr<xml_schema::buffer>; +.br + hexBinary std::[unique|auto]_ptr<xml_schema::buffer> +.br + std::[unique|auto]_ptr<xml_schema::buffer>; +.br + + date xml_schema::date; +.br + dateTime xml_schema::date_time; +.br + duration xml_schema::duration; +.br + gDay xml_schema::gday; +.br + gMonth xml_schema::gmonth; +.br + gMonthDay xml_schema::gmonth_day; +.br + gYear xml_schema::gyear; +.br + gYearMonth xml_schema::gyear_month; +.br + time xml_schema::time; +.br +} +.br +.RE + + +The last predefined rule maps anything that wasn't mapped by previous +rules to +.BR void : + +.RS +namespace .* +.br +{ +.br + .* void void; +.br +} +.br +.RE + +When you provide your own type maps with the +.B --type-map +option, they are evaluated first. This allows you to selectively override +predefined rules. + +.\" +.\" REGEX AND SHELL QUOTING +.\" +.SH REGEX AND SHELL QUOTING +When entering a regular expression argument in the shell command line +it is often necessary to use quoting (enclosing the argument in " " +or ' ') in order to prevent the shell from interpreting certain +characters, for example, spaces as argument separators and $ as +variable expansions. + +Unfortunately it is hard to achieve this in a manner that is portable +across POSIX shells, such as those found on GNU/Linux and UNIX, and +Windows shell. For example, if you use " " for quoting you will get +a wrong result with POSIX shells if your expression contains $. The +standard way of dealing with this on POSIX systems is to use ' ' +instead. Unfortunately, Windows shell does not remove ' ' from +arguments when they are passed to applications. As a result you may +have to use ' ' for POSIX and " " for Windows ($ is not treated as +a special character on Windows). + +Alternatively, you can save regular expression options into a file, +one option per line, and use this file with the +.B --options-file +option. With this approach you don't need to worry about shell quoting. + +.\" +.\" DIAGNOSTICS +.\" +.SH DIAGNOSTICS +If the input file is not a valid W3C XML Schema definition, +.B xsd +will issue diagnostic messages to +.B STDERR +and exit with non-zero exit code. +.SH BUGS +Send bug reports to the xsd-users@codesynthesis.com mailing list. +.SH COPYRIGHT +Copyright (c) 2005-2023 Code Synthesis. + +Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, +version 1.2; with no Invariant Sections, no Front-Cover Texts and +no Back-Cover Texts. Copy of the license can be obtained from +https://www.codesynthesis.com/licenses/fdl-1.2.txt diff --git a/xsd/doc/pregenerated/xsd.xhtml b/xsd/doc/pregenerated/xsd.xhtml new file mode 100644 index 0000000..2e30ed4 --- /dev/null +++ b/xsd/doc/pregenerated/xsd.xhtml @@ -0,0 +1,1620 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> +<head> + <title>XSD 4.2.1-a.0 Compiler Command Line Manual</title> + + <meta charset="UTF-8"/> + <meta name="version" content="4.2.1-a.0"/> + <meta name="copyright" content="© 2005-2023 Code Synthesis"/> + <meta name="keywords" content="xsd,xml,schema,c++,mapping,data,binding,code,generator,manual,man,page"/> + <meta name="description" content="XSD Compiler Command Line Manual"/> + + <link rel="stylesheet" type="text/css" href="default.css" /> + +<style type="text/css"> + + #synopsis { + list-style-type: none; + } + + #synopsis li { + padding-top : 0.0em; + padding-bottom : 0.0em; + } + + #commands dt { + padding-top : 0.4em; + } + + #commands dd { + padding-bottom : 0.4em; + padding-left : 2em; + } + + .options { + margin: 1em 0 1em 0; + } + + .options dt { + margin: 1em 0 0 0; + } + + .options dd { + margin: .1em 0 0 4.5em; + } + +</style> +</head> + +<body> +<div id="container"> + <div id="content"> + + <h1>NAME</h1> + + <p>xsd - W3C XML Schema to C++ Compiler</p> + + <h1>SYNOPSIS</h1> + + <dl id="synopsis"> + <dt><code><b>xsd</b> <i>command</i> [<i>options</i>] <i>file</i> [<i>file</i> ...]</code></dt> + <dt><code><b>xsd help</b> [<i>command</i>]</code></dt> + <dt><code><b>xsd version</b></code></dt> + </dl> + + <h1>DESCRIPTION</h1> + + <p><code><b>xsd</b></code> generates vocabulary-specific, statically-typed + C++ mapping from W3C XML Schema definitions. Particular mapping to + produce is selected by a <code><i>command</i></code>. Each mapping has + a number of mapping-specific <code><i>options</i></code> that should + appear, if any, after the <code><i>command</i></code>. Input files should + be W3C XML Schema definitions. The exact set of the generated files depends + on the selected mapping and options.</p> + + <h1>COMMANDS</h1> + + <dl id="commands"> + <dt><code><b>cxx-tree</b></code></dt> + <dd>Generate the C++/Tree mapping. For each input file in the form + <code><b>name.xsd</b></code> the following C++ files are generated: + <code><b>name.hxx</b></code> (header file), + <code><b>name.ixx</b></code> (inline file, generated only if the + <code><b>--generate-inline</b></code> option is specified), + <code><b>name.cxx</b></code> (source file), and + <code><b>name-fwd.hxx</b></code> (forward declaration file, generated + only if the <code><b>--generate-forward</b></code> option is + specified).</dd> + + <dt><code><b>cxx-parser</b></code></dt> + <dd>Generate the C++/Parser mapping. For each input file in the form + <code><b>name.xsd</b></code> the following C++ files are generated: + <code><b>name-pskel.hxx</b></code> (parser skeleton header file), + <code><b>name-pskel.ixx</b></code> (parser skeleton inline file, + generated only if the <code><b>--generate-inline</b></code> + option is specified), and + <code><b>name-pskel.cxx</b></code> (parser skeleton source file). + If the <code><b>--generate-noop-impl</b></code> or + <code><b>--generate-print-impl</b></code> option is specified, + the following additional sample implementation files are generated: + <code><b>name-pimpl.hxx</b></code> (parser implementation header + file) and + <code><b>name-pimpl.cxx</b></code> (parser implementation source + file). If the <code><b>--generate-test-driver</b></code> option + is specified, the additional <code><b>name-driver.cxx</b></code> + test driver file is generated.</dd> + + <dt><code><b>help</b></code></dt> + <dd>Print usage information and exit. Use + <p><code><b>xsd help</b> <i>command</i></code></p> + for command-specific help. + </dd> + + <dt><code><b>version</b></code></dt> + <dd>Print version and exit.</dd> + </dl> + + <h1>OPTIONS</h1> + + <p>Command-specific <code><i>options</i></code>, if any, should appear + after the corresponding <code><i>command</i></code>.</p> + + <h2>COMMON OPTIONS</h2> + <dl class="options"> + <dt><code><b>--std</b></code> <code><i>version</i></code></dt> + <dd>Specify the C++ standard that the generated code should conform to. + Valid values are <code><b>c++98</b></code>, <code><b>c++11</b></code> + (default), <code><b>c++14</b></code>, <code><b>c++17</b></code>, + <code><b>c++20</b></code>, and <code><b>c++23</b></code>. + + <p>The C++ standard affects various aspects of the generated code that are + discussed in more detail in various mapping-specific documentation. + Overall, when C++11 is selected, the generated code relies on the move + semantics and uses <code><b>std::unique_ptr</b></code> instead of + deprecated <code><b>std::auto_ptr</b></code>. Currently, there is no + difference between the C++11 and the later standards modes.</p> + + <p>When the C++11 mode is selected, you normally don't need to perform any + extra steps other than enable C++11 in your C++ compiler, if required. The + XSD compiler will automatically add the necessary macro defines to the + generated header files that will switch the header-only XSD runtime + library (<code><b>libxsd</b></code>) to the C++11 mode. However, if you + include any of the XSD runtime headers directly in your application + (normally you just include the generated headers), then you will need to + define the <code><b>XSD_CXX11</b></code> macro for your entire + project.</p></dd> + + <dt><code><b>--char-type</b></code> <code><i>type</i></code></dt> + <dd>Generate code using the provided character <code><i>type</i></code> + instead of the default <code><b>char</b></code>. Valid values are + <code><b>char</b></code> and <code><b>wchar_t</b></code>.</dd> + + <dt><code><b>--char-encoding</b></code> <code><i>enc</i></code></dt> + <dd>Specify the character encoding that should be used in the generated + code. Valid values for the <code><b>char</b></code> character type are + <code><b>utf8</b></code> (default), <code><b>iso8859-1</b></code>, + <code><b>lcp</b></code> (Xerces-C++ local code page), and + <code><b>custom</b></code>. If you pass <code><b>custom</b></code> as the + value then you will need to include the transcoder implementation header + for your encoding at the beginning of the generated header files (see the + <code><b>--hxx-prologue</b></code> option). + + <p>For the <code><b>wchar_t</b></code> character type the only valid value + is <code><b>auto</b></code> and the encoding is automatically selected + between UTF-16 and UTF-32/UCS-4, depending on the + <code><b>wchar_t</b></code> type size.</p></dd> + + <dt><code><b>--output-dir</b></code> <code><i>dir</i></code></dt> + <dd>Write generated files to <code><i>dir</i></code> instead of the + current directory.</dd> + + <dt><code><b>--generate-inline</b></code></dt> + <dd>Generate simple functions inline. This option triggers creation of the + inline file.</dd> + + <dt><code><b>--generate-xml-schema</b></code></dt> + <dd>Generate a C++ header file as if the schema being compiled defines the + XML Schema namespace. For the C++/Tree mapping, the resulting file will + contain definitions for all XML Schema built-in types. For the C++/Parser + mapping, the resulting file will contain definitions for all the parser + skeletons and implementations corresponding to the XML Schema built-in + types. + + <p>The schema file provided to the compiler need not exist and is only + used to derive the name of the resulting header file. Use the + <code><b>--extern-xml-schema</b></code> option to include this file in the + generated files for other schemas.</p></dd> + + <dt><code><b>--extern-xml-schema</b></code> <code><i>file</i></code></dt> + <dd>Include a header file derived from <code><i>file</i></code> instead of + generating the XML Schema namespace mapping inline. The provided file need + not exist and is only used to derive the name of the included header file. + Use the <code><b>--generate-xml-schema</b></code> option to generate this + header file.</dd> + + <dt><code><b>--namespace-map</b></code> <code><i>xns</i></code>=<code><i>cns</i></code></dt> + <dd>Map XML Schema namespace <code><i>xns</i></code> to C++ namespace + <code><i>cns</i></code>. Repeat this option to specify mapping for more + than one XML Schema namespace. For example, the following option: + + <p class="code"><code><b>--namespace-map + http://example.com/foo/bar=foo::bar</b></code></p> + + <p>Will map the <code><b>http://example.com/foo/bar</b></code> XML Schema + namespace to the <code><b>foo::bar</b></code> C++ namespace.</p></dd> + + <dt><code><b>--namespace-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema namespace names to C++ namespace names. + <code><i>regex</i></code> is a Perl-like regular expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. Any + character can be used as a delimiter instead of '<code><b>/</b></code>'. + Escaping of the delimiter character in <code><i>pattern</i></code> or + <code><i>replacement</i></code> is not supported. + + <p>All the regular expressions are pushed into a stack with the last + specified expression considered first. The first match that succeeds is + used. Regular expressions are applied to a string in the form</p> + + <p class="code"><code><i>filename</i> <i>namespace</i></code></p> + + <p>For example, if you have file <code><b>hello.xsd</b></code> with + namespace <code><b>http://example.com/hello</b></code> and you run + <code><b>xsd</b></code> on this file, then the string in question will + be:</p> + + <p class="code"><code><b>hello.xsd. + http://example.com/hello</b></code></p> + + <p>For the built-in XML Schema namespace the string is:</p> + + <p class="code"><code><b>XMLSchema.xsd + http://www.w3.org/2001/XMLSchema</b></code></p> + + <p>The following three steps are performed for each regular expression + until the match is found:</p> + + <p>1. The expression is applied and if the result is empty the next + expression is considered.</p> + + <p>2. All '<code><b>/</b></code>' are replaced with + '<code><b>::</b></code>'.</p> + + <p>3. The result is verified to be a valid C++ scope name (e.g., + <code><b>foo::bar</b></code>). If this test succeeds, the result is used + as a C++ namespace name.</p> + + <p>As an example, the following expression maps XML Schema namespaces in + the form <code><b>http://example.com/foo/bar</b></code> to C++ namespaces + in the form <code><b>foo::bar</b></code>:</p> + + <p class="code"><code><b>%.* http://example.com/(.+)%$1%</b></code></p> + + <p>See also the REGEX AND SHELL QUOTING section below.</p></dd> + + <dt><code><b>--namespace-regex-trace</b></code></dt> + <dd>Trace the process of applying regular expressions specified with the + <code><b>--namespace-regex</b></code> option. Use this option to find out + why your regular expressions don't do what you expected them to do.</dd> + + <dt><code><b>--reserved-name</b></code> <code><i>n</i></code>[=<code><i>r</i></code>]</dt> + <dd>Add name <code><i>n</i></code> to the list of names that should not be + used as identifiers. The name can optionally be followed by + <code><b>=</b></code> and the replacement name <code><i>r</i></code> that + should be used instead. All the C++ keywords are already in this + list.</dd> + + <dt><code><b>--include-with-brackets</b></code></dt> + <dd>Use angle brackets (<>) instead of quotes ("") in generated + <code><b>#include</b></code> directives.</dd> + + <dt><code><b>--include-prefix</b></code> <code><i>prefix</i></code></dt> + <dd>Add <code><i>prefix</i></code> to generated + <code><b>#include</b></code> directive paths. + + <p>For example, if you had the following import element in your schema</p> + + <p class="code"><code><b><import namespace="..." + schemaLocation="base.xsd"/></b></code></p> + + <p>and compiled this fragment with <code><b>--include-prefix + schemas/</b></code>, then the include directive in the generated code + would be:</p> + + <p class="code"><code><b>#include "schemas/base.hxx"</b></code></p></dd> + + <dt><code><b>--include-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to transform <code><b>#include</b></code> directive paths. + <code><i>regex</i></code> is a Perl-like regular expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. Any + character can be used as a delimiter instead of '<code><b>/</b></code>'. + Escaping of the delimiter character in <code><i>pattern</i></code> or + <code><i>replacement</i></code> is not supported. + + <p>All the regular expressions are pushed into a stack with the last + specified expression considered first. The first match that succeeds is + used.</p> + + <p>As an example, the following expression transforms paths in the form + <code><b>schemas/foo/bar</b></code> to paths in the form + <code><b>generated/foo/bar</b></code>:</p> + + <p class="code"><code><b>%schemas/(.+)%generated/$1%</b></code></p> + + <p>See also the REGEX AND SHELL QUOTING section below.</p></dd> + + <dt><code><b>--include-regex-trace</b></code></dt> + <dd>Trace the process of applying regular expressions specified with the + <code><b>--include-regex</b></code> option. Use this option to find out + why your regular expressions don't do what you expected them to do.</dd> + + <dt><code><b>--guard-prefix</b></code> <code><i>prefix</i></code></dt> + <dd>Add <code><i>prefix</i></code> to generated header inclusion guards. + The prefix is transformed to upper case and characters that are illegal in + a preprocessor macro name are replaced with underscores. If this option is + not specified then the directory part of the input schema file is used as + a prefix.</dd> + + <dt><code><b>--hxx-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use the provided <code><i>suffix</i></code> instead of the default + <code><b>.hxx</b></code> to construct the name of the header file. Note + that this suffix is also used to construct names of header files + corresponding to included/imported schemas.</dd> + + <dt><code><b>--ixx-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use the provided <code><i>suffix</i></code> instead of the default + <code><b>.ixx</b></code> to construct the name of the inline file.</dd> + + <dt><code><b>--cxx-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use the provided <code><i>suffix</i></code> instead of the default + <code><b>.cxx</b></code> to construct the name of the source file.</dd> + + <dt><code><b>--fwd-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use the provided <code><i>suffix</i></code> instead of the default + <code><b>-fwd.hxx</b></code> to construct the name of the forward + declaration file.</dd> + + <dt><code><b>--hxx-regex</b></code> <code><i>regex</i></code></dt> + <dd>Use the provided expression to construct the name of the header file. + <code><i>regex</i></code> is a Perl-like regular expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. + Note that this expression is also used to construct names of header files + corresponding to included/imported schemas. See also the REGEX AND SHELL + QUOTING section below.</dd> + + <dt><code><b>--ixx-regex</b></code> <code><i>regex</i></code></dt> + <dd>Use the provided expression to construct the name of the inline file. + <code><i>regex</i></code> is a Perl-like regular expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. See + also the REGEX AND SHELL QUOTING section below.</dd> + + <dt><code><b>--cxx-regex</b></code> <code><i>regex</i></code></dt> + <dd>Use the provided expression to construct the name of the source file. + <code><i>regex</i></code> is a Perl-like regular expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. See + also the REGEX AND SHELL QUOTING section below.</dd> + + <dt><code><b>--fwd-regex</b></code> <code><i>regex</i></code></dt> + <dd>Use the provided expression to construct the name of the forward + declaration file. <code><i>regex</i></code> is a Perl-like regular + expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. See + also the REGEX AND SHELL QUOTING section below.</dd> + + <dt><code><b>--hxx-prologue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the beginning of the header + file.</dd> + + <dt><code><b>--ixx-prologue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the beginning of the inline + file.</dd> + + <dt><code><b>--cxx-prologue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the beginning of the source + file.</dd> + + <dt><code><b>--fwd-prologue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the beginning of the forward + declaration file.</dd> + + <dt><code><b>--prologue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the beginning of each generated + file for which there is no file-specific prologue.</dd> + + <dt><code><b>--hxx-epilogue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the end of the header file.</dd> + + <dt><code><b>--ixx-epilogue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the end of the inline file.</dd> + + <dt><code><b>--cxx-epilogue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the end of the source file.</dd> + + <dt><code><b>--fwd-epilogue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the end of the forward declaration + file.</dd> + + <dt><code><b>--epilogue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the end of each generated file for + which there is no file-specific epilogue.</dd> + + <dt><code><b>--hxx-prologue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the beginning of + the header file.</dd> + + <dt><code><b>--ixx-prologue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the beginning of + the inline file.</dd> + + <dt><code><b>--cxx-prologue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the beginning of + the source file.</dd> + + <dt><code><b>--fwd-prologue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the beginning of + the forward declaration file.</dd> + + <dt><code><b>--prologue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the beginning of + each generated file for which there is no file-specific prologue + file.</dd> + + <dt><code><b>--hxx-epilogue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the end of the + header file.</dd> + + <dt><code><b>--ixx-epilogue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the end of the + inline file.</dd> + + <dt><code><b>--cxx-epilogue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the end of the + source file.</dd> + + <dt><code><b>--fwd-epilogue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the end of the + forward declaration file.</dd> + + <dt><code><b>--epilogue-file</b></code> <code><i>file</i></code></dt> + <dd>Insert the content of the <code><i>file</i></code> at the end of each + generated file for which there is no file-specific epilogue file.</dd> + + <dt><code><b>--export-symbol</b></code> <code><i>symbol</i></code></dt> + <dd>Insert <code><i>symbol</i></code> in places where DLL export/import + control statements (<code><b>__declspec(dllexport/dllimport)</b></code>) + are necessary.</dd> + + <dt><code><b>--export-xml-schema</b></code></dt> + <dd>Export/import types in the XML Schema namespace using the export + symbol provided with the <code><b>--export-symbol</b></code> option. The + <code><b>XSD_NO_EXPORT</b></code> macro can be used to omit this code + during C++ compilation, which may be useful if you would like to use the + same generated code across multiple platforms.</dd> + + <dt><code><b>--export-maps</b></code></dt> + <dd>Export polymorphism support maps from a Win32 DLL into which this + generated code is placed. This is necessary when your type hierarchy is + split across several DLLs since otherwise each DLL will have its own set + of maps. In this situation the generated code for the DLL which contains + base types and/or substitution group heads should be compiled with this + option and the generated code for all other DLLs should be compiled with + <code><b>--import-maps</b></code>. This option is only valid together with + <code><b>--generate-polymorphic</b></code>. The + <code><b>XSD_NO_EXPORT</b></code> macro can be used to omit this code + during C++ compilation, which may be useful if you would like to use the + same generated code across multiple platforms.</dd> + + <dt><code><b>--import-maps</b></code></dt> + <dd>Import polymorphism support maps to a Win32 DLL or executable into + which this generated code is linked. See the + <code><b>--export-maps</b></code> option documentation for details. This + options is only valid together with + <code><b>--generate-polymorphic</b></code>. The + <code><b>XSD_NO_EXPORT</b></code> macro can be used to omit this code + during C++ compilation, which may be useful if you would like to use the + same generated code across multiple platforms.</dd> + + <dt><code><b>--generate-dep</b></code></dt> + <dd>Generate <code><b>make</b></code> dependency information. This option + triggers the creation of the <code><b>.d</b></code> file containing the + dependencies of the generated files on the main schema file as well as all + the schema files that it includes/imports, transitively. This dependency + file is then normally included into the main <code><b>makefile</b></code> + to implement automatic dependency tracking. See also the + <code><b>--dep-*</b></code> options. + + <p>Note also that automatic dependency generation is not supported in the + file-per-type mode (<code><b>--file-per-type</b></code>). In this case, + all the generated files are produced with a single compiler invocation and + depend on all the schemas. As a result, it is easier to establish such a + dependency manually, perhaps with the help of the + <code><b>--file-list*</b></code> options.</p></dd> + + <dt><code><b>--generate-dep-only</b></code></dt> + <dd>Generate <code><b>make</b></code> dependency information only.</dd> + + <dt><code><b>--dep-phony</b></code></dt> + <dd>Generate phony targets for included/imported schema files, causing + each to depend on nothing. Such dummy rules work around + <code><b>make</b></code> errors caused by the removal of schema files + without also updating the dependency file to match.</dd> + + <dt><code><b>--dep-target</b></code> <code><i>target</i></code></dt> + <dd>Change the target of the dependency rule. By default it contains all + the generated C++ files as well as the dependency file itself, without any + directory prefixes. If you require multiple targets, then you can specify + them as a single, space-separated argument or you can repeat this option + multiple times.</dd> + + <dt><code><b>--dep-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use <code><i>suffix</i></code> instead of the default + <code><b>.d</b></code> to construct the name of the dependency file. See + also <code><b>--dep-file</b></code>.</dd> + + <dt><code><b>--dep-file</b></code> <code><i>path</i></code></dt> + <dd>Use <code><i>path</i></code> as the generated dependency file path + instead of deriving it from the input file name. Write the dependency + information to <code><b>stdout</b></code> if <code><i>path</i></code> is + <code><b>-</b></code>. See also <code><b>--dep-regex</b></code>.</dd> + + <dt><code><b>--dep-regex</b></code> <code><i>regex</i></code></dt> + <dd>Use the provided expression to construct the name of the dependency + file. <code><i>regex</i></code> is a Perl-like regular expression in the + form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. See + also the REGEX AND SHELL QUOTING section below.</dd> + + <dt><code><b>--disable-warning</b></code> <code><i>warn</i></code></dt> + <dd>Disable printing warning with id <code><i>warn</i></code>. If + <code><b>all</b></code> is specified for the warning id then all warnings + are disabled.</dd> + + <dt><code><b>--options-file</b></code> <code><i>file</i></code></dt> + <dd>Read additional options from <code><i>file</i></code>. Each option + should appearing on a separate line optionally followed by space and an + option value. Empty lines and lines starting with <code><b>#</b></code> + are ignored. Option values can be enclosed in double + (<code><b>"</b></code>) or single (<code><b>'</b></code>) quotes to + preserve leading and trailing whitespaces as well as to specify empty + values. If the value itself contains trailing or leading quotes, enclose + it with an extra pair of quotes, for example <code><b>'"x"'</b></code>. + Non-leading and non-trailing quotes are interpreted as being part of the + option value. + + <p>The semantics of providing options in a file is equivalent to providing + the same set of options in the same order on the command line at the point + where the <code><b>--options-file</b></code> option is specified except + that the shell escaping and quoting is not required. You can repeat this + option to specify more than one options file.</p></dd> + + <dt><code><b>--show-sloc</b></code></dt> + <dd>Show the number of generated physical source lines of code + (SLOC).</dd> + + <dt><code><b>--sloc-limit</b></code> <code><i>num</i></code></dt> + <dd>Check that the number of generated physical source lines of code + (SLOC) does not exceed <code><i>num</i></code>.</dd> + + <dt><code><b>--proprietary-license</b></code></dt> + <dd>Indicate that the generated code is licensed under a proprietary + license instead of the GPL.</dd> + + <dt><code><b>--custom-literals</b></code> <code><i>file</i></code></dt> + <dd>Load custom XML string to C++ literal mappings from + <code><i>file</i></code>. This mechanism can be useful if you are using a + custom character encoding and some of the strings in your schemas, for + example element/attribute names or enumeration values, contain non-ASCII + characters. In this case you will need to provide a custom mapping to C++ + literals for such strings. The format of this file is specified in the + <code><b>custom-literals.xsd</b></code> XML Schema file that can be found + in the documentation directory.</dd> + + <dt><code><b>--preserve-anonymous</b></code></dt> + <dd>Preserve anonymous types. By default anonymous types are automatically + named with names derived from the enclosing elements/attributes. Because + mappings implemented by this compiler require all types to be named, this + option is only useful if you want to make sure your schemas don't have + anonymous types.</dd> + + <dt><code><b>--show-anonymous</b></code></dt> + <dd>Show elements and attributes that are of anonymous types. This option + only makes sense together with the + <code><b>--preserve-anonymous</b></code> option.</dd> + + <dt><code><b>--anonymous-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to derive names for anonymous types from the enclosing + attributes/elements. <code><i>regex</i></code> is a Perl-like regular + expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. Any + character can be used as a delimiter instead of '<code><b>/</b></code>'. + Escaping of the delimiter character in <code><i>pattern</i></code> or + <code><i>replacement</i></code> is not supported. + + <p>All the regular expressions are pushed into a stack with the last + specified expression considered first. The first match that succeeds is + used. Regular expressions are applied to a string in the form</p> + + <p class="code"><code><i>filename</i> <i>namespace</i> + <i>xpath</i></code></p> + + <p>For instance:</p> + + <p class="code"><code><b>hello.xsd http://example.com/hello + element</b></code></p> + + <p class="code"><code><b>hello.xsd http://example.com/hello + type/element</b></code></p> + + <p>As an example, the following expression makes all the derived names + start with capital letters. This could be useful when your naming + convention requires type names to start with capital letters:</p> + + <p class="code"><code><b>%.* .* (.+/)*(.+)%\u$2%</b></code></p> + + <p>See also the REGEX AND SHELL QUOTING section below.</p></dd> + + <dt><code><b>--anonymous-regex-trace</b></code></dt> + <dd>Trace the process of applying regular expressions specified with the + <code><b>--anonymous-regex</b></code> option. Use this option to find out + why your regular expressions don't do what you expected them to do.</dd> + + <dt><code><b>--location-map</b></code> <code><i>ol</i></code>=<code><i>nl</i></code></dt> + <dd>Map the original schema location <code><i>ol</i></code> that is + specified in the XML Schema include or import elements to new schema + location <code><i>nl</i></code>. Repeat this option to map more than one + schema location. For example, the following option maps the + <code><b>http://example.com/foo.xsd</b></code> URL to the + <code><b>foo.xsd</b></code> local file. + + <p class="code"><code><b>--location-map + http://example.com/foo.xsd=foo.xsd</b></code></p></dd> + + <dt><code><b>--location-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to map schema locations that are specified in the XML Schema include or + import elements. <code><i>regex</i></code> is a Perl-like regular + expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. Any + character can be used as a delimiter instead of '<code><b>/</b></code>'. + Escaping of the delimiter character in <code><i>pattern</i></code> or + <code><i>replacement</i></code> is not supported. All the regular + expressions are pushed into a stack with the last specified expression + considered first. The first match that succeeds is used. + + <p>For example, the following expression maps URL locations in the form + <code><b>http://example.com/foo/bar.xsd</b></code> to local files in the + form <code><b>bar.xsd</b></code>:</p> + + <p class="code"><code><b>%http://.+/(.+)%$1%</b></code></p> + + <p>See also the REGEX AND SHELL QUOTING section below.</p></dd> + + <dt><code><b>--location-regex-trace</b></code></dt> + <dd>Trace the process of applying regular expressions specified with the + <code><b>--location-regex</b></code> option. Use this option to find out + why your regular expressions don't do what you expected them to do.</dd> + + <dt><code><b>--file-per-type</b></code></dt> + <dd>Generate a separate set of C++ files for each type defined in XML + Schema. Note that in this mode you only need to compile the root schema(s) + and the code will be generated for all included and imported schemas. This + compilation mode is primarily useful when some of your schemas cannot be + compiled separately or have cyclic dependencies which involve type + inheritance. Other options related to this mode are: + <code><b>--type-file-regex</b></code>, + <code><b>--schema-file-regex</b></code>, + <code><b>--fat-type-file</b></code>, and + <code><b>--file-list</b></code>.</dd> + + <dt><code><b>--type-file-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate type names to file names when the + <code><b>--file-per-type</b></code> option is specified. + <code><i>regex</i></code> is a Perl-like regular expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. Any + character can be used as a delimiter instead of '<code><b>/</b></code>'. + Escaping of the delimiter character in <code><i>pattern</i></code> or + <code><i>replacement</i></code> is not supported. All the regular + expressions are pushed into a stack with the last specified expression + considered first. The first match that succeeds is used. Regular + expressions are applied to a string in the form + + <p class="code"><code><i>namespace</i> <i>type-name</i></code></p> + + <p>For example, the following expression maps type <code><b>foo</b></code> + that is defined in the <code><b>http://example.com/bar</b></code> + namespace to file name <code><b>bar-foo</b></code>:</p> + + <p class="code"><code><b>%http://example.com/(.+) + (.+)%$1-$2%</b></code></p> + + <p>See also the REGEX AND SHELL QUOTING section below.</p></dd> + + <dt><code><b>--type-file-regex-trace</b></code></dt> + <dd>Trace the process of applying regular expressions specified with the + <code><b>--type-file-regex</b></code> option. Use this option to find out + why your regular expressions don't do what you expected them to do.</dd> + + <dt><code><b>--schema-file-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate schema file names when the + <code><b>--file-per-type</b></code> option is specified. + <code><i>regex</i></code> is a Perl-like regular expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. Any + character can be used as a delimiter instead of '<code><b>/</b></code>'. + Escaping of the delimiter character in <code><i>pattern</i></code> or + <code><i>replacement</i></code> is not supported. All the regular + expressions are pushed into a stack with the last specified expression + considered first. The first match that succeeds is used. Regular + Expressions are applied to the absolute filesystem path of a schema file + and the result, including the directory part, if any, is used to derive + the <code><b>#include</b></code> directive paths as well as the generated + C++ file paths. This option, along with + <code><b>--type-file-regex</b></code> are primarily useful to place the + generated files into subdirectories or to resolve file name conflicts. + + <p>For example, the following expression maps schema files in the + <code><b>foo/1.0.0/</b></code> subdirectory to the files in the + <code><b>foo/</b></code> subdirectory. As a result, the + <code><b>#include</b></code> directive paths for such schemas will be in + the <code><b>foo/schema.hxx</b></code> form and the generated C++ files + will be placed into the <code><b>foo/</b></code> subdirectory:</p> + + <p class="code"><code><b>%.*/foo/1.0.0/(.+)%foo/$1%</b></code></p> + + <p>See also the REGEX AND SHELL QUOTING section below.</p></dd> + + <dt><code><b>--schema-file-regex-trace</b></code></dt> + <dd>Trace the process of applying regular expressions specified with the + <code><b>--schema-file-regex</b></code> option. Use this option to find + out why your regular expressions don't do what you expected them to + do.</dd> + + <dt><code><b>--fat-type-file</b></code></dt> + <dd>Generate code corresponding to global elements into type files instead + of schema files when the <code><b>--type-file-regex</b></code> option is + specified. This option is primarily useful when trying to minimize the + amount of object code that is linked to an executable by packaging + compiled generated code into a static (archive) library.</dd> + + <dt><code><b>--file-list</b></code> <code><i>file</i></code></dt> + <dd>Write a list of generated C++ files to <code><i>file</i></code> or to + <code><b>stdout</b></code> if <code><i>file</i></code> is + <code><b>-</b></code>. This option is primarily useful in the + file-per-type compilation mode (<code><b>--file-per-type</b></code>) to + create a list of generated C++ files, for example, as a makefile + fragment.</dd> + + <dt><code><b>--file-list-only</b></code></dt> + <dd>Only write the list of C++ files that would be generated without + actually generating them. This option only makes sense together with + <code><b>--file-list</b></code>.</dd> + + <dt><code><b>--file-list-prologue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the beginning of the file list. As + a convenience, all occurrences of the <code><b>\n</b></code> character + sequence in <code><i>text</i></code> are replaced with new lines. This + option can, for example, be used to assign the generated file list to a + makefile variable.</dd> + + <dt><code><b>--file-list-epilogue</b></code> <code><i>text</i></code></dt> + <dd>Insert <code><i>text</i></code> at the end of the file list. As a + convenience, all occurrences of the <code><b>\n</b></code> character + sequence in <code><i>text</i></code> are replaced with new lines.</dd> + + <dt><code><b>--file-list-delim</b></code> <code><i>text</i></code></dt> + <dd>Delimit file names written to the file list with + <code><i>text</i></code> instead of new lines. As a convenience, all + occurrences of the <code><b>\n</b></code> character sequence in + <code><i>text</i></code> are replaced with new lines.</dd> + </dl> + + <h2>CXX-TREE COMMAND OPTIONS</h2> + <dl class="options"> + <dt><code><b>--generate-polymorphic</b></code></dt> + <dd>Generate polymorphism-aware code. Specify this option if you use + substitution groups or <code><b>xsi:type</b></code>. Use the + <code><b>--polymorphic-type</b></code> or + <code><b>--polymorphic-type-all</b></code> option to specify which type + hierarchies are polymorphic.</dd> + + <dt><code><b>--polymorphic-type</b></code> <code><i>type</i></code></dt> + <dd>Indicate that <code><i>type</i></code> is a root of a polymorphic type + hierarchy. The compiler can often automatically determine which types are + polymorphic based on the substitution group declarations. However, you may + need to use this option if you are not using substitution groups or if + substitution groups are defined in another schema. You need to specify + this option when compiling every schema file that references + <code><i>type</i></code>. The <code><i>type</i></code> argument is an XML + Schema type name that can be optionally qualified with a namespace in the + <code><i>namespace</i><b>#</b><i>name</i></code> form.</dd> + + <dt><code><b>--polymorphic-type-all</b></code></dt> + <dd>Indicate that all types should be treated as polymorphic.</dd> + + <dt><code><b>--polymorphic-plate</b></code> <code><i>num</i></code></dt> + <dd>Specify the polymorphic map plate the generated code should register + on. This functionality is primarily useful to segregate multiple schemas + that define the same polymorphic types.</dd> + + <dt><code><b>--ordered-type</b></code> <code><i>type</i></code></dt> + <dd>Indicate that element order in <code><i>type</i></code> is + significant. An example would be a complex type with unbounded choice as a + content model where the element order in XML has application-specific + semantics. For ordered types the compiler generates a special container + data member and a corresponding set of accessors and modifiers that are + used to capture the order of elements and, for mixed content, of text. + + <p>The <code><i>type</i></code> argument is an XML Schema type name that + can be optionally qualified with a namespace in the + <code><i>namespace</i><b>#</b><i>name</i></code> form. Note also that you + will need to specify this option when compiling every schema file that has + other ordered types derived from this type.</p></dd> + + <dt><code><b>--ordered-type-derived</b></code></dt> + <dd>Automatically treat types derived from ordered bases as also ordered. + This is primarily useful if you would like to be able to iterate over the + complete content using the content order container.</dd> + + <dt><code><b>--ordered-type-mixed</b></code></dt> + <dd>Automatically treat complex types with mixed content as ordered.</dd> + + <dt><code><b>--ordered-type-all</b></code></dt> + <dd>Indicate that element order in all types is significant.</dd> + + <dt><code><b>--order-container</b></code> <code><i>type</i></code></dt> + <dd>Specify a custom class template that should be used as a container for + the content order in ordered types instead of the default + <code><b>std::vector</b></code>. See <code><b>--ordered-type</b></code> + for more information on ordered type. This option is primarily useful if + you need to perform more complex lookups in the content order container, + for example by element id. In this case, a container like Boost + multi-index may be more convenient. Note that if using a custom container, + you will also most likely need to include the relevant headers using the + <code><b>--hxx-prologue*</b></code> options.</dd> + + <dt><code><b>--generate-serialization</b></code></dt> + <dd>Generate serialization functions. Serialization functions convert the + object model back to XML.</dd> + + <dt><code><b>--generate-ostream</b></code></dt> + <dd>Generate ostream insertion operators + (<code><b>operator<<</b></code>) for generated types. This allows + one to easily print a fragment or the whole object model for debugging or + logging.</dd> + + <dt><code><b>--generate-doxygen</b></code></dt> + <dd>Generate documentation comments suitable for extraction by the Doxygen + documentation system. Documentation from annotations is added to the + comments if present in the schema.</dd> + + <dt><code><b>--generate-comparison</b></code></dt> + <dd>Generate comparison operators (<code><b>operator==</b></code> and + <code><b>operator!=</b></code>) for complex types. Comparison is performed + member-wise.</dd> + + <dt><code><b>--generate-default-ctor</b></code></dt> + <dd>Generate default constructors even for types that have required + members. Required members of an instance constructed using such a + constructor are not initialized and accessing them results in undefined + behavior.</dd> + + <dt><code><b>--generate-from-base-ctor</b></code></dt> + <dd>Generate constructors that expect an instance of a base type followed + by all required members.</dd> + + <dt><code><b>--suppress-assignment</b></code></dt> + <dd>Suppress the generation of copy assignment operators for complex + types. If this option is specified, the copy assignment operators for such + types are declared private and left unimplemented.</dd> + + <dt><code><b>--generate-detach</b></code></dt> + <dd>Generate detach functions for required elements and attributes. Detach + functions for optional and sequence cardinalities are provided by the + respective containers. These functions, for example, allow you to move + sub-trees in the object model either within the same tree or between + different trees.</dd> + + <dt><code><b>--generate-wildcard</b></code></dt> + <dd>Generate accessors and modifiers as well as parsing and serialization + code for XML Schema wildcards (<code><b>any</b></code> and + <code><b>anyAttribute</b></code>). XML content matched by wildcards is + presented as DOM fragments. Note that you need to initialize the + Xerces-C++ runtime if you are using this option.</dd> + + <dt><code><b>--generate-any-type</b></code></dt> + <dd>Extract and store content of the XML Schema + <code><b>anyType</b></code> type as a DOM fragment. Note that you need to + initialize the Xerces-C++ runtime if you are using this option.</dd> + + <dt><code><b>--generate-insertion</b></code> <code><i>os</i></code></dt> + <dd>Generate data representation stream insertion operators for the + <code><i>os</i></code> output stream type. Repeat this option to specify + more than one stream type. The ACE CDR stream + (<code><b>ACE_OutputCDR</b></code>) and RPC XDR are recognized by the + compiler and the necessary <code><b>#include</b></code> directives are + automatically generated. For custom stream types use the + <code><b>--hxx-prologue*</b></code> options to provide the necessary + declarations.</dd> + + <dt><code><b>--generate-extraction</b></code> <code><i>is</i></code></dt> + <dd>Generate data representation stream extraction constructors for the + <code><i>is</i></code> input stream type. Repeat this option to specify + more than one stream type. The ACE CDR stream + (<code><b>ACE_InputCDR</b></code>) and RPC XDR are recognized by the + compiler and the necessary <code><b>#include</b></code> directives are + automatically generated. For custom stream types use the + <code><b>--hxx-prologue*</b></code> options to provide the necessary + declarations.</dd> + + <dt><code><b>--generate-forward</b></code></dt> + <dd>Generate a separate header file with forward declarations for the + types being generated.</dd> + + <dt><code><b>--suppress-parsing</b></code></dt> + <dd>Suppress the generation of the parsing functions and constructors. Use + this option to reduce the generated code size when parsing from XML is not + needed.</dd> + + <dt><code><b>--generate-element-type</b></code></dt> + <dd>Generate types instead of parsing and serialization functions for root + elements. This is primarily useful to distinguish object models with the + same root type but with different root elements.</dd> + + <dt><code><b>--generate-element-map</b></code></dt> + <dd>Generate a root element map that allows uniform parsing and + serialization of multiple root elements. This option is only valid + together with <code><b>--generate-element-type</b></code>.</dd> + + <dt><code><b>--generate-intellisense</b></code></dt> + <dd>Generate workarounds for IntelliSense bugs in Visual Studio 2005 + (8.0). When this option is used, the resulting code is slightly more + verbose. IntelliSense in Visual Studio 2008 (9.0) and later does not + require these workarounds. Support for IntelliSense in Visual Studio 2003 + (7.1) is improved with this option but is still incomplete.</dd> + + <dt><code><b>--omit-default-attributes</b></code></dt> + <dd>Omit attributes with default and fixed values from serialized XML + documents.</dd> + + <dt><code><b>--type-naming</b></code> <code><i>style</i></code></dt> + <dd>Specify the type naming convention that should be used in the + generated code. Valid styles are <code><b>knr</b></code> (default), + <code><b>ucc</b></code>, and <code><b>java</b></code>. See the NAMING + CONVENTION section below for more information.</dd> + + <dt><code><b>--function-naming</b></code> <code><i>style</i></code></dt> + <dd>Specify the function naming convention that should be used in the + generated code. Valid styles are <code><b>knr</b></code> (default), + <code><b>lcc</b></code>, <code><b>ucc</b></code>, and + <code><b>java</b></code>. See the NAMING CONVENTION section below for more + information.</dd> + + <dt><code><b>--type-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema type names to C++ type names. See the NAMING + CONVENTION section below for more information.</dd> + + <dt><code><b>--accessor-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema names of elements/attributes to C++ accessor + function names. See the NAMING CONVENTION section below for more + information.</dd> + + <dt><code><b>--one-accessor-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema names of elements/attributes with cardinality one + to C++ accessor function names. See the NAMING CONVENTION section below + for more information.</dd> + + <dt><code><b>--opt-accessor-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema names of elements/attributes with cardinality + optional to C++ accessor function names. See the NAMING CONVENTION section + below for more information.</dd> + + <dt><code><b>--seq-accessor-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema names of elements/attributes with cardinality + sequence to C++ accessor function names. See the NAMING CONVENTION section + below for more information.</dd> + + <dt><code><b>--modifier-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema names of elements/attributes to C++ modifier + function names. See the NAMING CONVENTION section below for more + information.</dd> + + <dt><code><b>--one-modifier-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema names of elements/attributes with cardinality one + to C++ modifier function names. See the NAMING CONVENTION section below + for more information.</dd> + + <dt><code><b>--opt-modifier-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema names of elements/attributes with cardinality + optional to C++ modifier function names. See the NAMING CONVENTION section + below for more information.</dd> + + <dt><code><b>--seq-modifier-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema names of elements/attributes with cardinality + sequence to C++ modifier function names. See the NAMING CONVENTION section + below for more information.</dd> + + <dt><code><b>--parser-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema element names to C++ parsing function names. See + the NAMING CONVENTION section below for more information.</dd> + + <dt><code><b>--serializer-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema element names to C++ serialization function names. + See the NAMING CONVENTION section below for more information.</dd> + + <dt><code><b>--const-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema-derived names to C++ constant names. See the + NAMING CONVENTION section below for more information.</dd> + + <dt><code><b>--enumerator-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema enumeration values to C++ enumerator names. See + the NAMING CONVENTION section below for more information.</dd> + + <dt><code><b>--element-type-regex</b></code> <code><i>regex</i></code></dt> + <dd>Add <code><i>regex</i></code> to the list of regular expressions used + to translate XML Schema element names to C++ element type names. See the + NAMING CONVENTION section below for more information.</dd> + + <dt><code><b>--name-regex-trace</b></code></dt> + <dd>Trace the process of applying regular expressions specified with the + name transformation options. Use this option to find out why your regular + expressions don't do what you expected them to do.</dd> + + <dt><code><b>--root-element-first</b></code></dt> + <dd>Treat only the first global element as a document root. By default all + global elements are considered document roots.</dd> + + <dt><code><b>--root-element-last</b></code></dt> + <dd>Treat only the last global element as a document root. By default all + global elements are considered document roots.</dd> + + <dt><code><b>--root-element-all</b></code></dt> + <dd>Treat all global elements as document roots. This is the default + behavior. By explicitly specifying this option you can suppress the + warning that is issued if more than one global element is defined.</dd> + + <dt><code><b>--root-element-none</b></code></dt> + <dd>Do not treat any global elements as document roots. By default all + global elements are considered document roots.</dd> + + <dt><code><b>--root-element</b></code> <code><i>element</i></code></dt> + <dd>Treat only <code><i>element</i></code> as a document root. Repeat this + option to specify more than one root element.</dd> + + <dt><code><b>--custom-type</b></code> <code><i>map</i></code></dt> + <dd>Use a custom C++ type instead of the generated class. The + <code><i>map</i></code> argument is in the form + <code><i>name</i>[<b>=</b><i>type</i>[<b>/</b><i>base</i>]]</code>, where + <i>name</i> is a type name as defined in XML Schema and <i>type</i> is a + C++ type name that should be used instead. If <i>type</i> is not present + or empty then the custom type is assumed to have the same name and be + defined in the same namespace as the generated class would have. If + <i>base</i> is specified then the generated class is still generated but + with that name.</dd> + + <dt><code><b>--custom-type-regex</b></code> <code><i>regex</i></code></dt> + <dd>Use custom C++ types instead of the generated classes. The + <code><i>regex</i></code> argument is in the form + <code><b>/</b><i>name-pat</i><b>/</b>[<i>type-sub</i><b>/</b>[<i>base-sub</i><b>/</b>]]</code>, + where <i>name-pat</i> is a regex pattern that will be matched against type + names as defined in XML Schema and <i>type-sub</i> is a C++ type name + substitution that should be used instead. If <i>type-sub</i> is not + present or its substitution results in an empty string then the custom + type is assumed to have the same name and be defined in the same namespace + as the generated class would have. If <i>base-sub</i> is present and its + substitution results in a non-empty string then the generated class is + still generated but with the result of this substitution as its name. The + pattern and substitutions are in the Perl regular expression format. See + also the REGEX AND SHELL QUOTING section below.</dd> + + <dt><code><b>--parts</b></code> <code><i>num</i></code></dt> + <dd>Split generated source code into <code><i>num</i></code> parts. This + is useful when translating large, monolithic schemas and a C++ compiler is + not able to compile the resulting source code at once (usually due to + insufficient memory).</dd> + + <dt><code><b>--parts-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use <code><i>suffix</i></code> instead of the default + '<code><b>-</b></code>' to separate the file name from the part + number.</dd> + </dl> + + <h2>CXX-PARSER COMMAND OPTIONS</h2> + <dl class="options"> + <dt><code><b>--type-map</b></code> <code><i>mapfile</i></code></dt> + <dd>Read XML Schema to C++ type mapping information from + <code><i>mapfile</i></code>. Repeat this option to specify several type + maps. Type maps are considered in order of appearance and the first match + is used. By default all user-defined types are mapped to + <code><b>void</b></code>. See the TYPE MAP section below for more + information.</dd> + + <dt><code><b>--xml-parser</b></code> <code><i>parser</i></code></dt> + <dd>Use <code><i>parser</i></code> as the underlying XML parser. Valid + values are <code><b>xerces</b></code> for Xerces-C++ (default) and + <code><b>expat</b></code> for Expat.</dd> + + <dt><code><b>--generate-validation</b></code></dt> + <dd>Generate validation code. The validation code ("perfect parser") + ensures that instance documents conform to the schema. Validation code is + generated by default when the selected underlying XML parser is + non-validating (<code><b>expat</b></code>).</dd> + + <dt><code><b>--suppress-validation</b></code></dt> + <dd>Suppress the generation of validation code. Validation is suppressed + by default when the selected underlying XML parser is validating + (<code><b>xerces</b></code>).</dd> + + <dt><code><b>--generate-polymorphic</b></code></dt> + <dd>Generate polymorphism-aware code. Specify this option if you use + substitution groups or <code><b>xsi:type</b></code>.</dd> + + <dt><code><b>--generate-noop-impl</b></code></dt> + <dd>Generate a sample parser implementation that does nothing (no + operation). The sample implementation can then be filled with the + application-specific code. For an input file in the form + <code><b>name.xsd</b></code> this option triggers the generation of two + additional C++ files in the form: <code><b>name-pimpl.hxx</b></code> + (parser implementation header file) and <code><b>name-pimpl.cxx</b></code> + (parser implementation source file).</dd> + + <dt><code><b>--generate-print-impl</b></code></dt> + <dd>Generate a sample parser implementation that prints the XML data to + <code>STDOUT</code>. For an input file in the form + <code><b>name.xsd</b></code> this option triggers the generation of two + additional C++ files in the form: <code><b>name-pimpl.hxx</b></code> + (parser implementation header file) and <code><b>name-pimpl.cxx</b></code> + (parser implementation source file).</dd> + + <dt><code><b>--generate-test-driver</b></code></dt> + <dd>Generate a test driver for the sample parser implementation. For an + input file in the form <code><b>name.xsd</b></code> this option triggers + the generation of an additional C++ file in the form + <code><b>name-driver.cxx</b></code>.</dd> + + <dt><code><b>--force-overwrite</b></code></dt> + <dd>Force overwriting of the existing implementation and test driver + files. Use this option only if you do not mind loosing the changes you + have made in the sample implementation or test driver files.</dd> + + <dt><code><b>--root-element-first</b></code></dt> + <dd>Indicate that the first global element is the document root. This + information is used to generate the test driver for the sample + implementation.</dd> + + <dt><code><b>--root-element-last</b></code></dt> + <dd>Indicate that the last global element is the document root. This + information is used to generate the test driver for the sample + implementation.</dd> + + <dt><code><b>--root-element</b></code> <code><i>element</i></code></dt> + <dd>Indicate that <code><i>element</i></code> is the document root. This + information is used to generate the test driver for the sample + implementation.</dd> + + <dt><code><b>--skel-type-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use the provided <code><i>suffix</i></code> instead of the default + <code><b>_pskel</b></code> to construct the names of the generated parser + skeletons.</dd> + + <dt><code><b>--skel-file-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use the provided <code><i>suffix</i></code> instead of the default + <code><b>-pskel</b></code> to construct the names of the generated parser + skeleton files.</dd> + + <dt><code><b>--impl-type-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use the provided <code><i>suffix</i></code> instead of the default + <code><b>_pimpl</b></code> to construct the names of the parser + implementations for the built-in XML Schema types as well as sample parser + implementations.</dd> + + <dt><code><b>--impl-file-suffix</b></code> <code><i>suffix</i></code></dt> + <dd>Use the provided <code><i>suffix</i></code> instead of the default + <code><b>-pimpl</b></code> to construct the names of the generated sample + parser implementation files.</dd> + </dl> + + <h1>NAMING CONVENTION</h1> + + <p>The compiler can be instructed to use a particular naming + convention in the generated code. A number of widely-used + conventions can be selected using the <code><b>--type-naming</b></code> + and <code><b>--function-naming</b></code> options. A custom + naming convention can be achieved using the + <code><b>--type-regex</b></code>, + <code><b>--accessor-regex</b></code>, + <code><b>--one-accessor-regex</b></code>, + <code><b>--opt-accessor-regex</b></code>, + <code><b>--seq-accessor-regex</b></code>, + <code><b>--modifier-regex</b></code>, + <code><b>--one-modifier-regex</b></code>, + <code><b>--opt-modifier-regex</b></code>, + <code><b>--seq-modifier-regex</b></code>, + <code><b>--parser-regex</b></code>, + <code><b>--serializer-regex</b></code>, + <code><b>--const-regex</b></code>, + <code><b>--enumerator-regex</b></code>, and + <code><b>--element-type-regex</b></code> options. + </p> + + <p>The <code><b>--type-naming</b></code> option specifies the + convention that should be used for naming C++ types. Possible + values for this option are <code><b>knr</b></code> (default), + <code><b>ucc</b></code>, and <code><b>java</b></code>. The + <code><b>knr</b></code> value (stands for K&R) signifies + the standard, lower-case naming convention with the underscore + used as a word delimiter, for example: <code>foo</code>, + <code>foo_bar</code>. The <code><b>ucc</b></code> (stands + for upper-camel-case) and + <code><b>java</b></code> values a synonyms for the same + naming convention where the first letter of each word in the + name is capitalized, for example: <code>Foo</code>, + <code>FooBar</code>.</p> + + <p>Similarly, the <code><b>--function-naming</b></code> option + specifies the convention that should be used for naming C++ + functions. Possible values for this option are <code><b>knr</b></code> + (default), <code><b>lcc</b></code>, <code><b>ucc</b></code>, and + <code><b>java</b></code>. The <code><b>knr</b></code> value (stands + for K&R) signifies the standard, lower-case naming convention + with the underscore used as a word delimiter, for example: + <code>foo()</code>, <code>foo_bar()</code>. The <code><b>lcc</b></code> + value (stands for lower-camel-case) signifies a naming convention + where the first letter of each word except the first is capitalized, + for example: <code>foo()</code>, <code>fooBar()</code>. The + <code><b>ucc</b></code> value (stands for upper-camel-case) signifies + a naming convention where the first letter of each word is capitalized, + for example: <code>Foo()</code>, <code>FooBar()</code>. + The <code><b>java</b></code> naming convention is similar to + the lower-camel-case one except that accessor functions are prefixed + with <code>get</code>, modifier functions are prefixed + with <code>set</code>, parsing functions are prefixed + with <code>parse</code>, and serialization functions are + prefixed with <code>serialize</code>, for example: + <code>getFoo()</code>, <code>setFooBar()</code>, + <code>parseRoot()</code>, <code>serializeRoot()</code>.</p> + + <p>Note that the naming conventions specified with the + <code><b>--type-naming</b></code> and + <code><b>--function-naming</b></code> options perform only limited + transformations on the names that come from the schema in the + form of type, attribute, and element names. In other words, to + get consistent results, your schemas should follow a similar + naming convention as the one you would like to have in the + generated code. Alternatively, you can use the + <code><b>--*-regex</b></code> options (discussed below) + to perform further transformations on the names that come from + the schema.</p> + + <p>The + <code><b>--type-regex</b></code>, + <code><b>--accessor-regex</b></code>, + <code><b>--one-accessor-regex</b></code>, + <code><b>--opt-accessor-regex</b></code>, + <code><b>--seq-accessor-regex</b></code>, + <code><b>--modifier-regex</b></code>, + <code><b>--one-modifier-regex</b></code>, + <code><b>--opt-modifier-regex</b></code>, + <code><b>--seq-modifier-regex</b></code>, + <code><b>--parser-regex</b></code>, + <code><b>--serializer-regex</b></code>, + <code><b>--const-regex</b></code>, + <code><b>--enumerator-regex</b></code>, and + <code><b>--element-type-regex</b></code> options allow you to + specify extra regular expressions for each name category in + addition to the predefined set that is added depending on + the <code><b>--type-naming</b></code> and + <code><b>--function-naming</b></code> options. Expressions + that are provided with the <code><b>--*-regex</b></code> + options are evaluated prior to any predefined expressions. + This allows you to selectively override some or all of the + predefined transformations. When debugging your own expressions, + it is often useful to see which expressions match which names. + The <code><b>--name-regex-trace</b></code> option allows you + to trace the process of applying regular expressions to + names.</p> + + <p>The value for the <code><b>--*-regex</b></code> options should be + a perl-like regular expression in the form + <code><b>/</b><i>pattern</i><b>/</b><i>replacement</i><b>/</b></code>. + Any character can be used as a delimiter instead of <code><b>/</b></code>. + Escaping of the delimiter character in <code><i>pattern</i></code> or + <code><i>replacement</i></code> is not supported. + All the regular expressions for each category are pushed into a + category-specific stack with the last specified expression + considered first. The first match that succeeds is used. For the + <code><b>--one-accessor-regex</b></code> (accessors with cardinality one), + <code><b>--opt-accessor-regex</b></code> (accessors with cardinality optional), and + <code><b>--seq-accessor-regex</b></code> (accessors with cardinality sequence) + categories the <code><b>--accessor-regex</b></code> expressions are + used as a fallback. For the + <code><b>--one-modifier-regex</b></code>, + <code><b>--opt-modifier-regex</b></code>, and + <code><b>--seq-modifier-regex</b></code> + categories the <code><b>--modifier-regex</b></code> expressions are + used as a fallback. For the <code><b>--element-type-regex</b></code> + category the <code><b>--type-regex</b></code> expressions are + used as a fallback.</p> + + <p>The type name expressions (<code><b>--type-regex</b></code>) + are evaluated on the name string that has the following + format:</p> + + <p><code>[<i>namespace</i> ]<i>name</i>[,<i>name</i>][,<i>name</i>][,<i>name</i>]</code></p> + + <p>The element type name expressions + (<code><b>--element-type-regex</b></code>), effective only when + the <code><b>--generate-element-type</b></code> option is specified, + are evaluated on the name string that has the following + format:</p> + + <p><code><i>namespace</i> <i>name</i></code></p> + + <p>In the type name format the <code><i>namespace</i></code> part + followed by a space is only present for global type names. For + global types and elements defined in schemas without a target + namespace, the <code><i>namespace</i></code> part is empty but + the space is still present. In the type name format after the + initial <code><i>name</i></code> component, up to three additional + <code><i>name</i></code> components can be present, separated + by commas. For example:</p> + + <p><code><b>http://example.com/hello type</b></code></p> + <p><code><b>foo</b></code></p> + <p><code><b>foo,iterator</b></code></p> + <p><code><b>foo,const,iterator</b></code></p> + + <p>The following set of predefined regular expressions is used to + transform type names when the upper-camel-case naming convention + is selected:</p> + + <p><code><b>/(?:[^ ]* )?([^,]+)/\u$1/</b></code></p> + <p><code><b>/(?:[^ ]* )?([^,]+),([^,]+)/\u$1\u$2/</b></code></p> + <p><code><b>/(?:[^ ]* )?([^,]+),([^,]+),([^,]+)/\u$1\u$2\u$3/</b></code></p> + <p><code><b>/(?:[^ ]* )?([^,]+),([^,]+),([^,]+),([^,]+)/\u$1\u$2\u$3\u$4/</b></code></p> + + <p>The accessor and modifier expressions + (<code><b>--*accessor-regex</b></code> and + <code><b>--*modifier-regex</b></code>) are evaluated on the name string + that has the following format:</p> + + <p><code><i>name</i>[,<i>name</i>][,<i>name</i>]</code></p> + + <p>After the initial <code><i>name</i></code> component, up to two + additional <code><i>name</i></code> components can be present, + separated by commas. For example:</p> + + <p><code><b>foo</b></code></p> + <p><code><b>dom,document</b></code></p> + <p><code><b>foo,default,value</b></code></p> + + <p>The following set of predefined regular expressions is used to + transform accessor names when the <code><b>java</b></code> naming + convention is selected:</p> + + <p><code><b>/([^,]+)/get\u$1/</b></code></p> + <p><code><b>/([^,]+),([^,]+)/get\u$1\u$2/</b></code></p> + <p><code><b>/([^,]+),([^,]+),([^,]+)/get\u$1\u$2\u$3/</b></code></p> + + <p>For the parser, serializer, and enumerator categories, the + corresponding regular expressions are evaluated on local names of + elements and on enumeration values, respectively. For example, the + following predefined regular expression is used to transform parsing + function names when the <code><b>java</b></code> naming convention + is selected:</p> + + <p><code><b>/(.+)/parse\u$1/</b></code></p> + + <p>The const category is used to create C++ constant names for the + element/wildcard/text content ids in ordered types.</p> + + <p>See also the REGEX AND SHELL QUOTING section below.</p> + + <h1>TYPE MAP</h1> + + <p>Type map files are used in C++/Parser to define a mapping between + XML Schema and C++ types. The compiler uses this information + to determine the return types of <code><b>post_*</b></code> + functions in parser skeletons corresponding to XML Schema + types as well as argument types for callbacks corresponding + to elements and attributes of these types.</p> + + <p>The compiler has a set of predefined mapping rules that map + built-in XML Schema types to suitable C++ types (discussed + below) and all other types to <code><b>void</b></code>. + By providing your own type maps you can override these predefined + rules. The format of the type map file is presented below: + </p> + + <pre> +namespace <schema-namespace> [<cxx-namespace>] +{ + (include <file-name>;)* + ([type] <schema-type> <cxx-ret-type> [<cxx-arg-type>];)* +} + </pre> + + <p>Both <code><i><schema-namespace></i></code> and + <code><i><schema-type></i></code> are regex patterns while + <code><i><cxx-namespace></i></code>, + <code><i><cxx-ret-type></i></code>, and + <code><i><cxx-arg-type></i></code> are regex pattern + substitutions. All names can be optionally enclosed in + <code><b>" "</b></code>, for example, to include white-spaces.</p> + + <p><code><i><schema-namespace></i></code> determines XML + Schema namespace. Optional <code><i><cxx-namespace></i></code> + is prefixed to every C++ type name in this namespace declaration. + <code><i><cxx-ret-type></i></code> is a C++ type name that is + used as a return type for the <code><b>post_*</b></code> functions. + Optional <code><i><cxx-arg-type></i></code> is an argument + type for callback functions corresponding to elements and attributes + of this type. If + <code><i><cxx-arg-type></i></code> is not specified, it defaults + to <code><i><cxx-ret-type></i></code> if <code><i><cxx-ret-type></i></code> + ends with <code><b>*</b></code> or <code><b>&</b></code> (that is, + it is a pointer or a reference) and + <code><b>const</b> <i><cxx-ret-type></i><b>&</b></code> + otherwise. + <code><i><file-name></i></code> is a file name either in the + <code><b>" "</b></code> or <code><b>< ></b></code> format + and is added with the <code><b>#include</b></code> directive to + the generated code.</p> + + <p>The <code><b>#</b></code> character starts a comment that ends + with a new line or end of file. To specify a name that contains + <code><b>#</b></code> enclose it in <code><b>" "</b></code>. + For example:</p> + + <pre> +namespace http://www.example.com/xmlns/my my +{ + include "my.hxx"; + + # Pass apples by value. + # + apple apple; + + # Pass oranges as pointers. + # + orange orange_t*; +} + </pre> + + <p>In the example above, for the + <code><b>http://www.example.com/xmlns/my#orange</b></code> + XML Schema type, the <code><b>my::orange_t*</b></code> C++ type will + be used as both return and argument types.</p> + + <p>Several namespace declarations can be specified in a single + file. The namespace declaration can also be completely + omitted to map types in a schema without a namespace. For + instance:</p> + + <pre> +include "my.hxx"; +apple apple; + +namespace http://www.example.com/xmlns/my +{ + orange "const orange_t*"; +} + </pre> + + <p>The compiler has a number of predefined mapping rules that can be + presented as the following map files. The string-based XML Schema + built-in types are mapped to either <code><b>std::string</b></code> + or <code><b>std::wstring</b></code> depending on the character type + selected with the <code><b>--char-type</b></code> option + (<code><b>char</b></code> by default). The binary XML Schema types are + mapped to either <code>std::unique_ptr<xml_schema::buffer></code> + or <code>std::auto_ptr<xml_schema::buffer></code> depending on the C++ + standard selected with the <code><b>--std</b></code> option + (<code><b>c++11</b></code> by default).</p> + + <pre> +namespace http://www.w3.org/2001/XMLSchema +{ + boolean bool bool; + + byte "signed char" "signed char"; + unsignedByte "unsigned char" "unsigned char"; + + short short short; + unsignedShort "unsigned short" "unsigned short"; + + int int int; + unsignedInt "unsigned int" "unsigned int"; + + long "long long" "long long"; + unsignedLong "unsigned long long" "unsigned long long"; + + integer "long long" "long long"; + + negativeInteger "long long" "long long"; + nonPositiveInteger "long long" "long long"; + + positiveInteger "unsigned long long" "unsigned long long"; + nonNegativeInteger "unsigned long long" "unsigned long long"; + + float float float; + double double double; + decimal double double; + + string std::string; + normalizedString std::string; + token std::string; + Name std::string; + NMTOKEN std::string; + NCName std::string; + ID std::string; + IDREF std::string; + language std::string; + anyURI std::string; + + NMTOKENS xml_schema::string_sequence; + IDREFS xml_schema::string_sequence; + + QName xml_schema::qname; + + base64Binary std::[unique|auto]_ptr<xml_schema::buffer> + std::[unique|auto]_ptr<xml_schema::buffer>; + hexBinary std::[unique|auto]_ptr<xml_schema::buffer> + std::[unique|auto]_ptr<xml_schema::buffer>; + + date xml_schema::date; + dateTime xml_schema::date_time; + duration xml_schema::duration; + gDay xml_schema::gday; + gMonth xml_schema::gmonth; + gMonthDay xml_schema::gmonth_day; + gYear xml_schema::gyear; + gYearMonth xml_schema::gyear_month; + time xml_schema::time; +} + </pre> + + <p>The last predefined rule maps anything that wasn't mapped by + previous rules to <code><b>void</b></code>:</p> + + <pre> +namespace .* +{ + .* void void; +} + </pre> + + + <p>When you provide your own type maps with the + <code><b>--type-map</b></code> option, they are evaluated first. + This allows you to selectively override predefined rules.</p> + + <h1>REGEX AND SHELL QUOTING</h1> + + <p>When entering a regular expression argument in the shell + command line it is often necessary to use quoting (enclosing + the argument in <code><b>" "</b></code> or + <code><b>' '</b></code>) in order to prevent the shell + from interpreting certain characters, for example, spaces as + argument separators and <code><b>$</b></code> as variable + expansions.</p> + + <p>Unfortunately it is hard to achieve this in a manner that is + portable across POSIX shells, such as those found on + GNU/Linux and UNIX, and Windows shell. For example, if you + use <code><b>" "</b></code> for quoting you will get a + wrong result with POSIX shells if your expression contains + <code><b>$</b></code>. The standard way of dealing with this + on POSIX systems is to use <code><b>' '</b></code> instead. + Unfortunately, Windows shell does not remove <code><b>' '</b></code> + from arguments when they are passed to applications. As a result you + may have to use <code><b>' '</b></code> for POSIX and + <code><b>" "</b></code> for Windows (<code><b>$</b></code> is + not treated as a special character on Windows).</p> + + <p>Alternatively, you can save regular expression options into + a file, one option per line, and use this file with the + <code><b>--options-file</b></code> option. With this approach + you don't need to worry about shell quoting.</p> + + <h1>DIAGNOSTICS</h1> + + <p>If the input file is not a valid W3C XML Schema definition, + <code><b>xsd</b></code> will issue diagnostic messages to STDERR + and exit with non-zero exit code.</p> + + <h1>BUGS</h1> + + <p>Send bug reports to the + <a href="mailto:xsd-users@codesynthesis.com">xsd-users@codesynthesis.com</a> mailing list.</p> + + </div> + <div id="footer"> + Copyright © 2005-2023 Code Synthesis. + + <div id="terms"> + Permission is granted to copy, distribute and/or modify this + document under the terms of the + <a href="https://www.codesynthesis.com/licenses/fdl-1.2.txt">GNU Free + Documentation License, version 1.2</a>; with no Invariant Sections, + no Front-Cover Texts and no Back-Cover Texts. + </div> + </div> +</div> +</body> +</html> diff --git a/xsd/doc/xsd-epilogue.1 b/xsd/doc/xsd-epilogue.1 index 192880c..9ab1952 100644 --- a/xsd/doc/xsd-epilogue.1 +++ b/xsd/doc/xsd-epilogue.1 @@ -65,6 +65,9 @@ The value (stands for lower-camel-case) signifies a naming convention where the first letter of each word except the first is capitalized, for example: foo(), fooBar(). The +.B ucc +value (stands for upper-camel-case) signifies a naming convention where the +first letter of each word is capitalized, for example: Foo(), FooBar(). The .B java naming convention is similar to the lower-camel-case one except that accessor functions are prefixed with get, modifier functions are prefixed with set, @@ -378,7 +381,6 @@ namespace http://www.example.com/xmlns/my .br .RE - The compiler has a number of predefined mapping rules that can be presented as the following map files. The string-based XML Schema built-in types are mapped to either @@ -389,6 +391,14 @@ depending on the character type selected with the .B --char-type option .RB ( char +by default). The binary XML Schema types are mapped to either +.B std::unique_ptr<xml_schema::buffer> +or +.B std::auto_ptr<xml_schema::buffer> +depending on the C++ standard selected with the +.B --std +option +.RB ( c++11 by default). .RS @@ -468,13 +478,13 @@ namespace http://www.w3.org/2001/XMLSchema QName xml_schema::qname; .br - base64Binary std::auto_ptr<xml_schema::buffer> + base64Binary std::[unique|auto]_ptr<xml_schema::buffer> .br - std::auto_ptr<xml_schema::buffer>; + std::[unique|auto]_ptr<xml_schema::buffer>; .br - hexBinary std::auto_ptr<xml_schema::buffer> + hexBinary std::[unique|auto]_ptr<xml_schema::buffer> .br - std::auto_ptr<xml_schema::buffer>; + std::[unique|auto]_ptr<xml_schema::buffer>; .br date xml_schema::date; diff --git a/xsd/doc/xsd-epilogue.xhtml b/xsd/doc/xsd-epilogue.xhtml index aef0418..178cf8b 100644 --- a/xsd/doc/xsd-epilogue.xhtml +++ b/xsd/doc/xsd-epilogue.xhtml @@ -38,14 +38,17 @@ <p>Similarly, the <code><b>--function-naming</b></code> option specifies the convention that should be used for naming C++ functions. Possible values for this option are <code><b>knr</b></code> - (default), <code><b>lcc</b></code>, and <code><b>java</b></code>. The - <code><b>knr</b></code> value (stands for K&R) signifies - the standard, lower-case naming convention with the underscore - used as a word delimiter, for example: <code>foo()</code>, - <code>foo_bar()</code>. The <code><b>lcc</b></code> value - (stands for lower-camel-case) signifies a naming convention - where the first letter of each word except the first is - capitalized, for example: <code>foo()</code>, <code>fooBar()</code>. + (default), <code><b>lcc</b></code>, <code><b>ucc</b></code>, and + <code><b>java</b></code>. The <code><b>knr</b></code> value (stands + for K&R) signifies the standard, lower-case naming convention + with the underscore used as a word delimiter, for example: + <code>foo()</code>, <code>foo_bar()</code>. The <code><b>lcc</b></code> + value (stands for lower-camel-case) signifies a naming convention + where the first letter of each word except the first is capitalized, + for example: <code>foo()</code>, <code>fooBar()</code>. The + <code><b>ucc</b></code> value (stands for upper-camel-case) signifies + a naming convention where the first letter of each word is capitalized, + for example: <code>Foo()</code>, <code>FooBar()</code>. The <code><b>java</b></code> naming convention is similar to the lower-camel-case one except that accessor functions are prefixed with <code>get</code>, modifier functions are prefixed @@ -287,7 +290,11 @@ namespace http://www.example.com/xmlns/my built-in types are mapped to either <code><b>std::string</b></code> or <code><b>std::wstring</b></code> depending on the character type selected with the <code><b>--char-type</b></code> option - (<code><b>char</b></code> by default).</p> + (<code><b>char</b></code> by default). The binary XML Schema types are + mapped to either <code>std::unique_ptr<xml_schema::buffer></code> + or <code>std::auto_ptr<xml_schema::buffer></code> depending on the C++ + standard selected with the <code><b>--std</b></code> option + (<code><b>c++11</b></code> by default).</p> <pre> namespace http://www.w3.org/2001/XMLSchema @@ -334,10 +341,10 @@ namespace http://www.w3.org/2001/XMLSchema QName xml_schema::qname; - base64Binary std::auto_ptr<xml_schema::buffer> - std::auto_ptr<xml_schema::buffer>; - hexBinary std::auto_ptr<xml_schema::buffer> - std::auto_ptr<xml_schema::buffer>; + base64Binary std::[unique|auto]_ptr<xml_schema::buffer> + std::[unique|auto]_ptr<xml_schema::buffer>; + hexBinary std::[unique|auto]_ptr<xml_schema::buffer> + std::[unique|auto]_ptr<xml_schema::buffer>; date xml_schema::date; dateTime xml_schema::date_time; diff --git a/xsd/doc/xsd-prologue.xhtml b/xsd/doc/xsd-prologue.xhtml index e52e1fc..6782a32 100644 --- a/xsd/doc/xsd-prologue.xhtml +++ b/xsd/doc/xsd-prologue.xhtml @@ -1,10 +1,9 @@ -<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> - +<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>$project$ $version$ Compiler Command Line Manual</title> + <meta charset="UTF-8"/> <meta name="version" content="$version$"/> <meta name="copyright" content="© $copyright$"/> <meta name="keywords" content="xsd,xml,schema,c++,mapping,data,binding,code,generator,manual,man,page"/> |