<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://www.terracotta.org/config" version="7" xmlns="http://www.terracotta.org/config" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType> <xs:all> <xs:annotation> <xs:documentation> This section defines the tc-properties which the user wants to set The order in which the properties would be overridden is the following tc-properties from the installation jar tc-properties from the tc-config tc-properties from local tc.properties file tc-properties set via system properties Note that the local tc.properties has higher preference than this section </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> The 'system' section contains configuration data that affects the entire Terracotta system as a whole; things like the configuration mode go here. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> This section defines the servers present in your Terracotta system. You can omit this section entirely, in which case it behaves as if there's a single server with all values set at their default. You can include exactly one server entry here (the common case), or, if you're going to run multiple servers for failover, you can include multiple servers here. If you include more than one server here, note that each server will need to know which configuration it should use as it starts up. If you name your servers according to the host that they run on (and no host contains more than one server), then they will find the hostname themselves and work automatically. If you name your servers in any other fashion (and, again, only if there is more than one 'server' element present here), then you will need to pass the command-line option "-n <![CDATA[ <name> ]]> " to the start-tc-server script, passing it the name of a server configuration from this file. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> This section contains settings that affect all clients that connect to the system. Note that while these settings are applied uniformly across all clients, this does not prevent you from applying different settings to various clients. There are two ways of doing this: Certain parameters ('logs', below) undergo parameter expansion before being used by the client. This allows you to use various predefined substitutions (like '%h' for host), or a general one (%(myprop) to use the value of Java system property 'myprop'), for these values; expansions are carried out in each client's JVM independently. For each client to have its own configuration you can set 'tc.config' to the configuration file. If the configuration model is production then the 'application' section for all of the clients comes from the application section of the server's config file. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> This section contains items that affect the core behavior of Terracotta as it relates to your application. This data must be kept consistent across clients and servers in order for Terracotta to function properly, and so the system will enforce this. </xs:documentation> </xs:annotation> </xs:element> </xs:all> </xs:complexType> </xs:element> <xs:restriction base="xs:token"> <xs:pattern value="(@[A-Za-z_0-9$\*\.]+ )*[@A-Za-z_0-9$\*\.]+\+?"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="(@[A-Za-z_0-9$\*\.]+ )*([A-Za-z_0-9$\*\.\[\] \+]+ )[A-Za-z_0-9$\*\.\+]+(\([A-Za-z_0-9$,\*\. \[\]]*\))"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="(@[A-Za-z_0-9$\*\.]+ ){0,1}([A-Za-z_0-9$\*\.\[\] \+]){2,}"/> </xs:restriction> </xs:simpleType> <!-- <xs:simpleType name="method-name-expression"> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_0-9$\. \[\]]+(\([A-Za-z_0-9$,\. \[\]]*\))" /> </xs:restriction> </xs:simpleType> --> <xs:restriction base="xs:token"> <xs:enumeration value="write"/> <xs:enumeration value="read"/> <xs:enumeration value="concurrent"/> <xs:enumeration value="synchronous-write"/> </xs:restriction> </xs:simpleType> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:sequence maxOccurs="unbounded"> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> Declares a DSO root. A root can have a name that defaults to its fully qualified field name. </xs:documentation> </xs:annotation> <xs:all> </xs:all> <!-- switch to this later on and use substitutionGroup for members within the choice section when xmlbeans actually support substitutionGroups <xs:sequence minOccurs="1" maxOccurs="1"> <xs:element name="root-name" type="qualified-class-name" minOccurs="0" /> <xs:choice minOccurs="1" maxOccurs="1"> <xs:element name="field-name" type="qualified-field-name" /> <xs:element name="field-expression" type="field-expression" /> </xs:choice> </xs:sequence> --> </xs:complexType> <xs:sequence> </xs:sequence> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:choice> </xs:choice> </xs:complexType> <xs:sequence maxOccurs="unbounded"> </xs:sequence> </xs:complexType> <xs:sequence> <xs:complexType> <xs:simpleContent> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:sequence> </xs:sequence> </xs:complexType> <xs:simpleContent> <xs:extension base="xs:token"> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:sequence> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> Identifies a set of web applications and/or named classloaders which can be substituted at runtime for the purpose of loading shared data into different applications. For example, two web applications running on different Terracotta nodes can share the same root, by declaring both web applications to be in the same app-group; or a web application and a command-line application can share a root by declaring the web application and the standard system classloader to be in the same app-group. It is an error to declare the same application in more than one app-group. Each Terracotta client node can only run at most one application per app-group; for example, if web-applications A and B are in the same app-group, it is an error to deploy both A and B to the same app server instance. </xs:documentation> </xs:annotation> <xs:sequence> </xs:sequence> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> <xs:annotation> <xs:documentation xmlns="http://www.w3.org/1999/xhtml"> When an attempt is made to distribute a non-portable object, the object (and any objects to which it refers) will be logged in the terracotta log file. </xs:documentation> </xs:annotation> </xs:element> </xs:all> </xs:complexType> <xs:sequence> </xs:sequence> </xs:complexType> <xs:sequence> </xs:sequence> </xs:complexType> <xs:sequence> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> Declares a class field into which an instance will be injected by DSO. The type of the instance is by default specified by the type of the field, but it can also be specified by the instance-type element if needed. </xs:documentation> </xs:annotation> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> <xs:element default="com.terracotta.management.keychain.FileStoreKeyChain" maxOccurs="1" minOccurs="0" name="class" type="non-blank-token"/> </xs:all> </xs:complexType> <xs:all> <xs:element default="com.tc.net.core.security.ShiroIniRealm" maxOccurs="1" minOccurs="0" name="realm" type="non-blank-token"/> </xs:all> </xs:complexType> <xs:restriction base="xs:token"> <xs:enumeration value="temporary-swap-only"/> <xs:enumeration value="permanent-store"/> </xs:restriction> </xs:simpleType> <xs:sequence> </xs:sequence> </xs:complexType> <xs:all> <xs:element default="temporary-swap-only" maxOccurs="1" minOccurs="0" name="mode" type="persistence-mode"/> </xs:all> </xs:complexType> <xs:all> <xs:element default="120" maxOccurs="1" minOccurs="0" name="client-reconnect-window" type="non-negative-int"/> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:annotation> <xs:documentation> Identifies a module/version to use, this module must be located in either a) the default repository shipped with Terracotta or b) one of the repositories listed in the <![CDATA[ <module> ]]> section. </xs:documentation> </xs:annotation> </xs:complexType> <xs:sequence maxOccurs="unbounded"> </xs:sequence> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" minOccurs="0" name="non-distributed-field" type="java-identifier"/> </xs:sequence> </xs:complexType> <xs:simpleContent> <xs:extension base="xs:boolean"> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:annotation> <xs:documentation xmlns="http://www.w3.org/1999/xhtml"> Describes the authentication mode, which can be either a JAAS LoginConfig name or a JMX password-file location. If unset or empty, the default JMX password-file location is used. </xs:documentation> </xs:annotation> <xs:choice> <xs:element default="%(java.home)/lib/management/jmxremote.password" minOccurs="0" name="password-file" type="path"/> </xs:choice> </xs:complexType> <xs:all> <xs:element default="%(java.home)/lib/management/jmxremote.access" minOccurs="0" name="access-file" type="path"/> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:all> </xs:all> </xs:complexType> <xs:sequence maxOccurs="unbounded" minOccurs="0"> </xs:sequence> </xs:complexType> </xs:complexType> <xs:annotation> <xs:documentation xmlns="http://www.w3.org/1999/xhtml"> Data specific to one of your servers. </xs:documentation> </xs:annotation> <xs:all> <xs:annotation> <xs:documentation xmlns="http://www.w3.org/1999/xhtml"> Turn on JMX authentication for the Terracotta Server, Enterprise Edition. An empty tag <authentication/> defaults to the standard Java JMX authentication mechanism referring to password and access files in: $JAVA_HOME/jre/lib/management. <ul> <li>$JAVA_HOME/jre/lib/management/jmxremote.password</li> <li>$JAVA_HOME/jre/lib/management/jmxremote.access</li> </ul> You must modify these files as such (if none exist create them): <p>jmxremote.password</p> add a line to the end of the file declaring your username and password followed by a caridge return: <p>secretusername secretpassword</p> <p>jmxremote.access</p> add the following line (with a caridge return) to the end of your file: <p>secretusername readwrite</p> You must also: <br/> $ chmod 500 jmxremote.password <br/> $ chown <user who will execute the tc-server> jmxremote.password </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation xmlns="http://www.w3.org/1999/xhtml"> Turn on authentication for the embedded Terracotta HTTP Server. This requires a properties file that contains the users and passwords that have access to the HTTP server. <br/> The format of the properties file is: <p>username: password [,rolename ...]</p> The supported roles and protected sections are: <ul> <li> <code>statistics</code> (for the statistics gatherer at <code>/statistics-gatherer</code> ) </li> </ul> Passwords may be clear text, obfuscated or checksummed. The class <code>com.mortbay.Util.Password</code> should be used to generate obfuscated passwords or password checksums. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Where should the server store its persistent data? (This includes stored object data for DSO.) This value undergoes parameter substitution before being used; this allows you to use placeholders like '%h' (for the hostname) or '%(com.mycompany.propname)' (to substitute in the value of Java system property 'com.mycompany.propname'). Thus, a value of 'server-data-%h' would expand to 'server-data-artichoke' if running on host 'artichoke'. If this is a relative path, then it is interpreted relative to the current working directory of the server (that is, the directory you were in when you started the server). It is thus recommended that you specify an absolute path here. Default: 'data' This places the 'data' directory in the directory you were in when you invoked 'start-tc-server'. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Where should the server store its search index data? If this is a relative path, then it is interpreted relative to the current working directory of the server (that is, the directory you were in when you started the server). It is thus recommended that you specify an absolute path here. Default: "index" relative to the server's data path </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> In which directory should the server store its log files? Again, this value undergoes parameter substitution before being used; thus, a value like 'server-logs-%h' would expand to 'server-logs-artichoke' if running on host 'artichoke'. If this is a relative path, then it is interpreted relative to the current working directory of the server (that is, the directory you were in when you started server). It is thus recommended that you specify an absolute path here. Default: 'logs' This places the 'logs' directory in the directory you were in when you invoked 'start-tc-server'. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Where the data should be stored in case a backup call is initiated. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> In which directory should the server store statistics data that is being buffered? Again, this value undergoes parameter substitution before being used; thus, a value like 'statistics-data-%h' would expand to 'statistics-data' if running on host 'artichoke'. If this is a relative path, then it is interpreted relative to the current working directory of the server (that is, the directory you were in when you started server). It is thus recommended that you specify an absolute path here. Default: 'statistics' This places the 'statistics' directory in the directory you were in when you invoked 'start-tc-server'. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> On what port should the DSO server listen for connections from DSO clients? This can be any port you like, but note that ports below 1024 typically require 'root' privileges to use on Unix-style systems (Linux, Solaris). Default:9510 </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> On what port should the server listen for connections from the Terracotta administration console? This can be any port you like, but note that ports below 1024 typically require 'root' privileges to use on Unix-style systems (Linux, Solaris). Default: "dso-port" + 10 </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Port for server to server communication which must be indicated when HA mode is networked-active-passive. This can be any port you like, but note that ports below 1024 typically require 'root' privileges to use on Unix-style systems (Linux, Solaris). Default: "dso-port" + 20 </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Configuration data for DSO that's specific to the DSO server. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Configuration of this server's security, ie: SSL and authentication. </xs:documentation> </xs:annotation> </xs:element> </xs:all> <xs:annotation> <xs:documentation> The host that the server runs on, expansion parameters may be used in this attribute. Defaults to "%i" (the machine IP address). </xs:documentation> </xs:annotation> </xs:attribute> <xs:annotation> <xs:documentation> The symbolic name of the server, expansion parameters may be used. Defaults to "host:dso-port". </xs:documentation> </xs:annotation> </xs:attribute> <xs:annotation> <xs:documentation> The address this server should bind its network listeners to. By default network listeners will be available on all local addresses (ie. 0.0.0.0) </xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> <xs:annotation> <xs:documentation> This section contains settings that affect all clients that connect to the system. Note that while these settings are applied uniformly across all clients, this does not prevent you from applying different settings to various clients. There are two ways of doing this: - Certain parameters ('logs', below) undergo parameter expansion before being used by the client. This allows you to use various predefined substitutions (like '%h' for host), or a general one (%(myprop) to use the value of Java system property 'myprop'), for these values; expansions are carried out in each client's JVM independently. - For each client to have its own configuration you can set 'tc.config' to the configuration file. If the configuration model is production then the 'application' section for all of the clients comes from the application section of the server's config file. </xs:documentation> </xs:annotation> <xs:all> <xs:annotation> <xs:documentation> This section contains the list of modules to use in the client. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Where should the client write its log files? This value undergoes parameter substitution before being used; thus, a value like 'client-logs-%h' would expand to 'client-logs-banana' if running on host 'banana'. If this is a relative path, then it is interpreted relative to the current working directory of the client (that is, the directory you were in when you started the program that uses Terracotta services). It is thus recommended that you specify an absolute path here. Default: 'logs-%i'; this places the logs in a directory relative to the directory you were in when you invoked the program that uses Terracotta services (your client), and calls that directory, for example, 'logs-10.0.0.57' if the machine that the client is on has assigned IP address 10.0.0.57. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> This section contains data for Terracotta DSO that's specific to the DSO client only. </xs:documentation> </xs:annotation> </xs:element> </xs:all> </xs:complexType> <xs:annotation> <xs:documentation> This section contains items that affect the core behavior of Terracotta as it relates to your application. This data must be kept consistent across clients and servers in order for Terracotta to function properly, and so the system will enforce this; see the comments for the 'configuration-model' switch, above, for more details. </xs:documentation> </xs:annotation> <xs:all> <xs:annotation> <xs:documentation> This section controls how Terracotta DSO behaves in your application. </xs:documentation> </xs:annotation> </xs:element> </xs:all> </xs:complexType> <xs:annotation> <xs:documentation> This section defines the servers present in your Terracotta system. You can omit this section entirely, in which case it behaves as if there's a single server with all values set at their default. You can include exactly one server entry here (the common case), or, if you're going to run multiple servers for failover, you can include multiple servers here. If you include more than one server here, note that each server will need to know which configuration it should use as it starts up. If you name your servers according to the host that they run on (and no host contains more than one server), then they will find the hostname themselves and work automatically. If you name your servers in any other fashion (and, again, only if there is more than one 'server' element present here), then you will need to pass the command-line option "-n <![CDATA[ <name> ]]> " to the start-tc-server script, passing it the name of a server configuration from this file. </xs:documentation> </xs:annotation> <xs:sequence maxOccurs="1" minOccurs="0"> </xs:sequence> </xs:complexType> <xs:simpleContent> <xs:annotation> <xs:documentation> The address this server should bind its network listeners to. By default network listeners will be available on all local addresses (ie. 0.0.0.0) </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:annotation> <xs:documentation/> </xs:annotation> <xs:sequence maxOccurs="unbounded"> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation/> </xs:annotation> <xs:all> </xs:all> </xs:complexType> <xs:annotation> <xs:documentation/> </xs:annotation> <xs:sequence maxOccurs="unbounded" minOccurs="1"> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> The configuration model: 'development' or 'production'. The clients can each have their own configuration file or all use the server's configuration file. The server's configuration file is located at http://localhost:9515/config If the configuration model is production then the 'application' section for all of the clients comes from the application section of the server's config file. If the configuration model is development then each of the clients's 'application' section is determined by their own configuration file. </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:enumeration value="development"/> <xs:enumeration value="production"/> </xs:restriction> </xs:simpleType> <xs:annotation> <xs:documentation> What type of license is in use? This can be 'trial' or 'production', and does not affect the behavior of the system other than ensuring that the license in use matches this type. (This prevents you from accidentally putting a trial license onto your production server and then panicking thirty days later when that license expires.) DEPRECATED: license file must be installed to Terracotta installation directory. </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:enumeration value="none"/> <xs:enumeration value="trial"/> <xs:enumeration value="production"/> </xs:restriction> </xs:simpleType> <xs:all> <xs:annotation> <xs:documentation> Where is the license file? Each server must have access to this file (which may be a relative or absolute path). This item can use parameter substitution, which allows you to insert data like '%h' and have it expand to the current hostname; this allows flexibility in the case where different servers have their license file in different locations. DEPRECATED: license file must be installed to Terracotta installation directory. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> What type of license is in use? This can be 'trial' or 'production', and does not affect the behavior of the system other than ensuring that the license in use matches this type. (This prevents you from accidentally putting a trial license onto your production server and then panicking thirty days later when that license expires.) DEPRECATED: license file must be installed to Terracotta installation directory. </xs:documentation> </xs:annotation> </xs:element> </xs:all> </xs:complexType> <xs:annotation> <xs:documentation> The 'system' section contains configuration data that affects the entire Terracotta system as a whole; things like whether to activate DSO services go here. </xs:documentation> </xs:annotation> <xs:all> <xs:annotation> <xs:documentation> The 'license' element requires a 'location' and 'type' to be specified. If you omit the 'license' element, Terracotta will run in a limited 'initial' mode, which limits server runtime and limits the maximum number of simultaneously-connected clients. DEPRECATED: license file must be installed to Terracotta installation directory. </xs:documentation> </xs:annotation> </xs:element> <xs:element default="development" minOccurs="0" name="configuration-model" type="configuration-model"/> </xs:all> </xs:complexType> <xs:restriction base="xs:token"> <xs:enumeration value="networked-active-passive"/> <xs:enumeration value="disk-based-active-passive"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:annotation> <xs:documentation> Several different predefined substitutions are available for your use: %h expands to the fully-qualified host name of the machine running your application %i expands to the IP adress of the machine running your application %H refers to the home directory of the user running running your application %n refers to the username of the user running running your application %o refers to the name of the operating system running your application %a refers to the processor architecture of the machine running running your application %v refers to the version of the operating system running running your application %t refers to the temporary directory of the machine running your application(on Linux or Solaris, e.g., /tmp) %(property) refers to the java system property of the JVM running on the machine(e.g. %(java.home) ) </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="unlimited"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="none"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:positiveInteger"> <xs:maxInclusive value="2147483647"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:nonNegativeInteger"> <xs:maxInclusive value="2147483647"/> </xs:restriction> </xs:simpleType> </xs:simpleType> <xs:restriction base="xs:nonNegativeInteger"> <xs:minInclusive value="0"/> <xs:maxInclusive value="65535"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="collapse"/> <xs:minLength value="1"/> <xs:maxLength value="255"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_][A-Za-z_0-9$]*(\.[A-Za-z_][A-Za-z_0-9$]*)*"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_][A-Za-z_0-9$]*"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_][A-Za-z_0-9$]*(\.[A-Za-z_][A-Za-z_0-9$]*)+"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_][A-Za-z_0-9$]*"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_][A-Za-z_0-9$]*"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_][A-Za-z_0-9$]*(\.[A-Za-z_][A-Za-z_0-9$]*)+"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_][A-Za-z_0-9$]*(\.[A-Za-z_][A-Za-z_0-9$]*)*"/> </xs:restriction> </xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z_][A-Za-z_0-9$]*"/> </xs:restriction> </xs:simpleType> <xs:annotation> <xs:documentation> Terracotta Plug-in configuration element </xs:documentation> </xs:annotation> </xs:element> </xs:schema> |
This XML schema documentation has been generated with DocFlex/XML RE 1.7.2 using DocFlex/XML XSDDoc 2.1.0 template set. DocFlex/XML RE is a reduced edition of DocFlex/XML, which is a tool for programming and running highly sophisticated documentation and reports generators by the data obtained from any kind of XML files. The actual doc-generators are implemented in the form of special templates that are designed visually using a high quality Template Designer GUI basing on the XML schema (or DTD) files describing the data source XML. DocFlex/XML XSDDoc is a commercial template application of DocFlex/XML that implements a high-end XML Schema documentation generator with simultaneous support of framed multi-file HTML, single-file HTML and RTF output formats. (More formats are planned in the future). A commercial license for "DocFlex/XML XSDDoc" will allow you:
Once having only such a license, you will be able to run the fully-featured XML schema documentation generator both with DocFlex/XML SDK and with DocFlex/XML RE, which is a reduced free edition containing only the template interpretor / output generator. No other licenses will be required! But this is not all. In addition to it, a commercial license for DocFlex/XML SDK will allow you to modify the XSDDoc templates themselves as much as you want. You will be able to achieve whatever was impossible to do with the template parameters only. And, of course, you could develop any template applications by your own! Please note: By purchasing a license for this software, you not only acquire a useful tool, you will also make an important investment in its future development, the result of which you could enjoy later by yourself. Every single your purchase matters and makes a difference for us! To buy a license, please follow this link: http://www.filigris.com/shop/ |