XMLBeans includes several command-line tools you might find handy as shortcuts for common tasks. You'll find these tools in the bin directory of the XMLBeans installation or source tree.
Prints the contents of an XSB file in human-readable form. An XSB file contains schema meta information needed to perform tasks such as binding and validation. "XSB" stands for XML Schema Binary.
dumpxsb myfile.xsb
The following command and output example use an XSB file generated by compiling the schema (in EasyPo.xsd) that accompanies the SubstitutionGroup sample.
dumpxsb PurchaseOrderDocument.xsb
Output:
PurchaseOrderDocument.xsb Magic cookie: da7ababe Major version: 2 Minor version: 22 Release number: 0 Filetype: FILETYPE_SCHEMAPOINTER String pool (2): 1 = "schema.system.s633ECC92E6CC0ACA137B11B7B38CA3A8" Type system: schema.system.s633ECC92E6CC0ACA137B11B7B38CA3A8
Generates XML schema from XML instance files.
inst2xsd [options] instance.xml*
The following example generates schema0.xsd from Purchase-Order.xml, with salami slice schema design, simple content types detected where possible, and enumerations limited to elements with four different values.
inst2xsd -design ss -simple-content-types smart -enumerations 4 Purchase-Order.xml
Compiles schema into Java XMLBeans classes and metadata. Schema-related work with XMLBeans begins by compiling schema to generated Java types. You can use scomp to compile schema from the command line. XMLBeans also provides an Ant task, xmlbeans, which you can use to compile schemas. For run-time schema compilation that doesn't generate files, see the org.apache.xmlbeans.XmlBeans.compileXsd methods.
For more information about the types resulting from compiling schema, see Java Types Generated from User-Derived Schema Types, XMLBeans Support for Built-In Schema Types, and Methods for Types Generated From Schema.
For more information on getting started with XMLBeans, see Getting Started with XMLBeans.
scomp [options] [dirs]* [schemaFile.xsd]* [service.wsdl]* [config.xsdconfig]*
##local to
specify the no-namespace in that list. org.apache.xml.resolver.tools.CatalogResolver for
resolving. Note that to use this option, your classpath must include resolver.jar
from http://xml.apache.org/commons/components/resolver/index.html). Copy resolver.jar
to the XMLBEANS_HOME/lib directory, so that the script can pick it up from
there. You can use the sdownload tool to ensure that
required schemas are present for compilation. In the following example, scomp compiles EasyPO.xsd, guiding type naming with po.xsdconfig. scomp puts generated CLASS and XSB files into a classes directory one level up, and JAVA source files into a src directory one level up. Source files will be compatible with Java version 1.5.
scomp -d ..\classes -src ..\src -javasource 1.5 EasyPO.xsd po.xsdconfig
Here, scomp compiles all of the contents of the schemas directory and puts the generated files into poschema.jar one level up.
scomp -out ..\poschema.jar schemas
The following example generates JAVA source and XSB files from the schema in EasyPO.xsd. No CLASS files are generated, and the JAVA and XSB files are put into src and xsb directories, respectively.
scomp -srconly -src ..\src -d ..\xsb EasyPO.xsd
When the schema features imports or includes and you want to use a catalog,
you can tell scomp to use the default catalog resolver (org.apache.xml.resolver.tools.CatalogResolver);
you specify a catalog file with the -catalog option, as in the example below.
(Note that this requires resolver.jar, as noted above for the -catalog option.)
In this example, scomp compiles schemaThatUsesRequiredSchema.xsd into myschemas.jar,
resolving imports from requiredSchema.xsd through xsdownload.xml. The sdownload
tool is executed first — this ensures that requiredSchema.xsd is present
for compilation, but does not actually download requiredSchema.xsd unless the
URL at which it's found isn't already cached. This is more efficient than using
scomp's -dl option, which attempts to download every time.
sdownload "http://some.org/requiredSchema.xsd" scomp -out ..\myschemas.jar -catalog xsdownload.xml schemaThatUsesRequiredSchema.xsd
When a schema features multiple element declarations of the same qname, such as multiple <xs:any> particles, you might want to disable to "unique particle validation" rule, which would ordinarily invalidate the schema. To do this, use the -noupa option, as in the following example.
scomp -out ..\myschemas.jar -noupa schemas
Copies the XML schema at the specified URL to the specified file.
schemacopy sourceurl [targetfile]
Maintains "xsdownload.xml," an index of locally downloaded XSD files. URLs that are specified are downloaded if they aren't already cached. If no files or URLs are specified, all indexed files are relevant.
You can use this tool when using scomp, in conjunction with scomp's -catalog option, to ensure the presence of schemas that are required for compilation because they're imported or included. This is an alternative to using scomp's -dl option, which would hit the Internet on every invocation of scomp. When you use sdownload with -catalog, the download occurs only if the URL is not already cached. See the scomp section for an example.
sdownload [-dir directory] [-refresh] [-recurse] [-sync] [url/file]
Factors redundant definitions out of a set of schemas and uses imports instead.
sfactor [-import common.xsd] [-out outputdir] inputdir [-license]
Validates the specified instance against the specified schema. Unlike the validate tool, svalidate uses a streaming model through which you can validate much larger instances with less memory (if the schema permits it).
svalidate [options] schema.xsd instance.xml
Validates a the specified instance against the specified schema. Compare this tool with the svalidate tool, which is useful for validating very large documents.
validate [options] schema.xsd instance.xml
The following simple example validates PurchaseOrder.xml against EasyPO.xsd.
validate ..\schemas\EasyPO.xsd PurchaseOrder.xml
In this example, MySchema imports types from another schema and also includes multiple particles defined as <xsd:any> types. The validate command here locates the external schemas for importing (providing there is network access to the schemas) and ignores the validation rule whereby multiple particles of the same qname render the schema invalid.
validate -dl -noupa ..\schemas\MySchema.xsd AnInstance.xml
Pretty prints the specified XML to the console.
xpretty [options] file.xml
Prints an XML instance from the specified global element using the specified schema.
xsd2inst schemafile.xsd -name globalElementName
The following command and output use the schema that accompanies the SubstitutionGroup sample.
xsd2inst easypo.xsd -name invoice-header
Output
<eas:invoice-header xmlns:eas="http://xmlbeans.apache.org/samples/substitutiongroup/easypo">
<eas:ship-to>
<eas:name>string</eas:name>
<eas:address>string</eas:address>
</eas:ship-to>
<eas:bill-to>
<eas:name>string</eas:name>
<eas:address>string</eas:address>
</eas:bill-to>
<!--Optional:-->
<eas:product id="3"/>
<!--Optional:-->
<eas:comment>string</eas:comment>
</eas:invoice-header>
Prints inheritance hierarchy of types defined in a schema.
xsdtree [-noanon] [-nopvr] [-noupa] [-partial] [-license] schemafile.xsd*
The following command and output use the schema that accompanies the SubstitutionGroup sample.
xsdtree easypo.xsd
Output:
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:eas="http://xmlbeans.apache.org/samples/substitutiongroup/easypo"
+-xs:anyType (builtin)
+-xs:anySimpleType (builtin)
| +-xs:string (builtin)
| +-xs:normalizedString (builtin)
| +-xs:token (builtin)
| +-type of color element in eas:clothing-type (enumeration)
+-type of element eas:invoice-header
+-type of element eas:purchase-order
+-eas:product-type
| +-eas:clothing-type
| +-eas:book-type
+-eas:name-address
Compiles a set of XSD and/or WSDL files into XMLBeans types. See xmlbean Ant Task for more complete documentation on the task.