pub.schema:createXSD
WmPublic. Creates an XML Schema definition from a document type, from the input and output parameters of a service, or from a specification.
Input Parameters
name | String Fully qualified name of a document type, service, or specification on the Integration Server. |
Output Parameters
isSuccessful | String Flag indicating whether the schema definition was created successfully. A value of:  true indicates that the schema definition was created successfully. false indicates that the schema definition was not created successfully. See errors for detailed information. |
xsd | Document Conditional. The schema definition xsd has the following keys: |
| Key | Description |
| url | String Conditional. Relative url of the generated schema. |
| source | String Conditional. Schema definition. |
errors | Document List Conditional. List of fatal errors, if any, that occurred when generating the XSD. Each document in the list has the following structure: |
| Key | Description |
| error Message | String Text of the error message. |
| When fatal errors occur, the service does not generate an XSD file. |
warnings | Document List Conditional. List of non-fatal errors, if any, that were encountered while generating the XSD. Each document in the list has the following structure: |
| Key | Description |
| warningMessage | String Text of the warning message. |
| When non-fatal errors occur, the service generates the XSD file but also returns warnings to indicate that it encountered unusual or unexpected conditions during the process. |
Usage Notes
If the document type, service signature, or specification you are providing as input to createXSD contains fields that belong to multiple XML namespaces, createXSD generates multiple XML Schema definitions (one for each XML namespace) and imports them into the XML Schema contained in the source field. These imported XML Schema definitions appear as children of xsd in the pipeline.
When using createXSD to create an XML Schema definition, keep the following points in mind:
Top-level strings are not allowed.
String tables beneath the top-level are not allowed.
Field names cannot contain a prefix without an associated XML namespace.
Fields of type other than scalar string cannot have names that begin with the character
@ or be named
*body.
Fields at the same level (that is, beneath the same parent field in the input or output of the same signature) can have the same name but different types or properties. However, only one field's type and properties is used for all fields with that name at that level. Because the method used to select the field is not defined,
Software AG recommends avoiding this case.
Only one field named
*body can occur at the same level.
Duplicate field names that begin with the character
@ cannot repeat at the same level.
Fields at different levels can have the same name with duplicate XML namespace values, even if the fields have different types or properties. However, only one field's type and properties are used for all fields with that name at that level. Because the method used to select the field is not defined,
Software AG recommends avoiding this case.
Object constraints are allowed. However, the
Integration Server does not represent them in the XSD.
Strings constrained by older schema types (types defined before the W3C XML 2001 Schema recommendations) are allowed. However, the
Integration Server translates them into 2001 XML Schema types.
If a document variable is considered to be open (the Allow unspecified fields property is set to true),
Integration Server adds an xsd:any element to the complex type definition that corresponds to the document variable. However, when the watt.core.schema.createSchema.omitXSDAny server configuration parameter is set to true,
Integration Server omits the xsd:any element even when the document is considered to be open. For more information about this server configuration parameter, see
webMethods Integration Server Administrator’s Guide.
If you use createXSD to create multiple XML Schema definitions that refer to each other, place the XSD files in the same folder or base path. To ensure that the references resolve correctly, make sure the relative URLs specified in the XSD files reflect the names of the XSD files within this folder or base path.