diff GEMBASSY-1.0.3/gsoap/wsdl/README.txt @ 0:8300eb051bea draft

Initial upload

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/GEMBASSY-1.0.3/gsoap/wsdl/README.txt	Fri Jun 26 05:19:29 2015 -0400
@@ -0,0 +1,215 @@
+The gSOAP WSDL parser 'wsdl2h'
+
+INSTRUCTIONS
+
+The gSOAP WSDL parser converts one or more WSDLs into a gSOAP header file for
+processing with the gSOAP soapcpp2 compiler to generate client stubs/proxies
+and server skeletons/objects to access services or build new services.
+
+For example:
+
+$ wsdl2h -o XMethodsQuery.h http://www.xmethods.net/wsdl/query.wsdl
+
+Note: if an error occurs when running wsdl2h, please try again later. The
+XMethods site is very popular and suffers under load. It may also be the case
+that XMethods removed certain services. In that case, try another on-line WSDL.
+
+This generates the XMethodsQuery.h header file with Web service operations
+and C++ data types. This header file is intended to be processed with soapcpp2
+to generate the stub and/or skeleton code.
+
+You need to have stlvector.h present in the current directory (stlvector.h is
+in the package) to support STL vectors. To build without STL, use option -s:
+
+$ wsdl2h -s -o XMethodsQuery.h http://www.xmethods.net/wsdl/query.wsdl
+
+Or to build a pure C application, use option -c:
+
+$ wsdl2h -c -o XMethodsQuery.h http://www.xmethods.net/wsdl/query.wsdl
+
+Other useful options to control the output are -e and -y (see below).
+
+The above commands are to be followed by the soapcpp2 compilation phase:
+
+$ soapcpp2 -C XMethodsQuery.h
+
+Where option -C indicates client-side only files (soapcpp2 generates both
+client and server stubs and skeletons by default).
+
+The generated XMethodsQuery.h includes the definitions of data types and
+service operations of the XMethods Query Web service. To develop a C++ client
+application, you can use the generated 'soapXMethodsQuerySoapProxy' class and
+'XMethodsQuerySoap.nsmap' XML namespace table to access the Web service. Both
+need to be '#include'd in your source. Then compile and link the soapC.cpp,
+soapClient.cpp, and stdsoap2.cpp sources to complete the build. More
+information on this process can be found in the gSOAP documentation.
+
+When parsing a WSDL, the output file name is the WSDL input file name with
+extension '.h' instead of '.wsdl'. When an input file is absent or a WSDL file
+from a Web location is accessed, the header output will be produced on the
+standard output. Input may also consist of schema files, which is useful when
+you to need to generate code for serializing schema instances.
+
+USING A TYPEMAP FILE TO CONTROL THE INPUT AND OUTPUT
+
+The typemap.dat is the default file processed by 'wsdl2h' to customize the
+generated header file output. The default typemap.dat file is located in the
+'WS' directory. Use wsdl2h option -t to specify an alternate file.
+
+The typemap.dat file can be used to define namespace prefix and type bindings
+for the generated header files by the 'wsdl2h' tool. XML namespace prefix
+bindings can be provided to override the default choice of the ns1, ns2, ...
+prefixes generated by 'wsdl2h'. It is highly recommended to provide namespace
+prefixes for your project's XML namespaces. In this way, changes to the WSDL
+(or newer releases of wsdl2h) will have a minimal impact on coding.
+
+Bindings for namespace prefixes in typemap.dat are of the form:
+	prefix = "URI"
+
+For example, to bind the 'google' prefix to the Google API's namespace:
+	google = "urn:GoogleSearch"
+
+Type bindings can by provided to bind XML schema types to C/C++ types for your
+project.
+
+Type bindings are of the form:
+	prefix__type = declaration | use | ptr-use
+where 'declaration' introduces the type in the header file, 'use' specifies how
+the type is used directly, 'ptr-use' specifies how the type is used as a
+pointer type.
+
+For example:
+	xsd__string = | char* | char*
+After enabling this line, all XSD strings will be mapped to char* and since
+char* is already a pointer type, the 'ptr-use' part is the same as 'use' part.
+Note that the 'declaration' part is empty in these cases.
+
+Member data and functions can be provided to extend a generated struct or
+class.
+
+Class and struct extensions are of the form:
+	prefix__type = $ member-declaration
+
+For example, to add a constructor and destructor to class myns__record:
+	myns__record = $ myns__record();
+	myns__record = $ ~myns__record();
+
+To specify a set of input files in typemap.dat for wsdl2h to process, use '<':
+< infile1.wsdl
+< infile2.xsd
+< http://www.example.com/example.wsdl
+
+To specify the default output file, use '>', for example:
+> example.h
+
+Any other material to be included in the generated header file can be provided
+by enclosing the text within brackets [ and ]. Brackets MUST appear at the
+start of a new line.
+
+For example, to include a note:
+[
+// TODO: Don't forget to bind the namespace prefixes!
+]
+This comment appears as the first line in the generated header file.
+
+INPUT FORMATS
+
+wsdl2h reads from standard input or the files provided at the command line:
+
+wsdl2h [options] [-o outfile.h] [infile1.wsdl infile2.wsdl infile3.xsd ... ]
+
+Valid input file formats are .wsdl and .xsd (schema) files.
+
+Multiple wsdl and schema files can be given, which results in a consolidated
+header file with all definitions combined.
+
+OUTPUT FORMAT
+
+The output file is a gSOAP-formatted header file. The header file syntax is
+augmented with annotations reflecting WSDL and schema-specific bindings and
+validation constraints.
+
+We suggest the use of Doxygen (www.doxygen.org) to produce documented for the
+generated header file. However, we STRONGLY recommend user to inspect the
+generated header file first for warnings and other annotations (which do not
+appear in Doxygen's output) indicating potential problems.
+
+Note that Doxygen's license model does not infinge on your ownership of the
+generated gSOAP source code output when you purchased a commercial license.
+
+COMMAND LINE OPTIONS
+
+-a      generate indexed struct names for local elements with anonymous types
+-b	bi-directional operations to serve one-way response messages (duplex)
+-c      generate C source code
+-d      use DOM to populate xs:any and xsd:anyType elements
+-e      don't qualify enum names
+-f      generate flat C++ class hierarchy
+-g      generate global top-level element declarations
+-h      display help info
+-Ipath  use path to find files
+-i      don't import (advanced option)
+-j	don't generate SOAP_ENV__Header and SOAP_ENV__Detail definitions
+-k	don't generate SOAP_ENV__Header mustUnderstand qualifiers
+-l      include license information in output
+-m      use xsd.h module to import primitive types
+-Nname  use name for service prefixes to produce a service for each binding
+-nname  use name as the base namespace prefix instead of 'ns'
+-ofile  output to file
+-P      don't create polymorphic types with C++ inheritance from xsd__anyType
+-p      create polymorphic types with C++ inheritance from base xsd__anyType
+-qname  use name for the C++ namespace for all service declarations
+-rhost[:port[:uid:pwd]]
+        connect via proxy host, port, and proxy credentials
+-r:uid:pwd
+        connect with authentication credentials (digest auth requires SSL)
+-R      generate REST operations for REST bindings in the WSDL
+-s      don't generate STL code (no std::string and no std::vector)
+-tfile  use type map file instead of the default file typemap.dat
+-u      don't generate unions
+-v      verbose output
+-W      suppress warnings
+-w      always wrap response parameters in a response struct (<=1.1.4 behavior)
+-x      don't generate _XML any/anyAttribute extensibility elements
+-y      generate typedef synonyms for structs and enums
+-z1     compatibility with 2.7.6e: generate pointer-based arrays
+-z2     compatibility with 2.7.15: qualify element/attribute referenced members
+-z3     compatibility with 2.7.16 to 2.8.7: qualify element/attribute references
+-z4     compatibility up to 2.8.11: don't generate union structs in std::vector
+-z5     compatibility up to 2.8.15
+-_      don't generate _USCORE (replace with UNICODE _x005f)
+infile.wsdl infile.xsd http://www... list of input sources (if none use stdin)
+
+DOCUMENTATION
+
+See soapdoc2.pdf for documentation.
+
+INSTALLATION
+
+Use './configure' and 'make' in the root directory, as explained in the 
+installation instructions.
+
+To build 'wsdl2h' when autoconf/automake fail, use:
+
+	make -f MakefileManual
+
+ENABLING HTTPS SSL/TLS CONNECTIVITY AND HTTP DIGEST AUTHENTICATION
+
+To build 'wsdl2h' with secure features, use:
+
+	make -f MakefileManual secure
+
+If you don't have OpenSSL installed, you cannot build an SSL-secure version of
+wsdl2h. In that case we recommend downloading the WSDL and schema files for
+processing with the non-SSL-enabled wsdl2h tool.
+
+LICENSE
+
+The gSOAP WSDL parser 'wsdl2h' and source code are released under GPL or
+a commercial license. The commercial license is available from Genivia.
+Please visit http://genivia.com/Products/gsoap/contract.html
+
+COPYRIGHT NOTICE
+
+gSOAP XML Web services tools
+Copyright (C) 2000-2013, Robert van Engelen, Genivia, Inc. All Rights Reserved.