Introduction to Schema Type Signatures

When you compile schema, the API generated from your schema is integrated with the XMLBeans type system that represents the underlying XML schema. All together, these types make up the schema type system to which your code has access. When handling XML based on the schema, you typically call methods of the API generated when you compiled the schema. However, for the cases when you want to get information about the schema itself, you use the schema type system API.

In the XMLBeans API, you have access to the system itself through SchemaTypeSystem and related classes. These make up a kind of "meta-API," or a view on the schema. You can use the schema type system API to discover the type system at run time. See the reference topic on that interface for an overview of the schema type system.

Schema Type "Signatures"

A schema is made up of schema components. Schema components are the pieces of a schema, such as a type definition, an element declaration, attribute declaration, and so on. To mirror these in the schema type system, a SchemaComponent instance represents a component in the underlying schema; separate components have corresponding types. For example you would have a SchemaType object for a CustomerType your schema defined, or a SchemaGlobalElement object for a global PurchaseOrder element. You would also have a SchemaType for built-in schema types, such as xs:string or xs:datetime. XMLBean provides a "signature" to describe each type. You can retrieve this signature by calling the SchemaType class's toString method.

The toString method returns XMLBeans' version of a unique signature for a schema type. This string is useful for debugging because it describes a given type even when the type doesn't have a name.

Note: It's important to remember that this signature is an XMLBeans convention, rather than a standard from the schema working group. The working group has not yet standardized a signature for XML schema types. As a result the signature you'll see from XMLBeans is subject to change — whatever the schema working group comes up with in the end (if anything) is probably what will be used by this API. In other words, don't write a program to decode the signature.

You can use the following description to understand how a signature is constructed.

An Example

So, for example, if you have a type that describes the list items within an attribute of an instance that looks like this:

 <root mylist="432 999 143 123"/>
The schema, if done with lots of nested types, could look something like this:
<schema targetNamespace="myNamespace" elementFormDefault="qualified">
    <element name="root">
        <complexType>
            <attribute name="mylist">
                <simpleType>
                    <list>
                        <simpleType> <!--This is the type that the signature is for -->
                            <restriction base="xs:nonNegativeInteger">
                                <totalDigits value="3"/>..
The signature for the simpleType indicated in the example would be:
I=|A=mylist|E=root|D=root@myNamespace

You could read this as:

"The type of the list item | within the type of the mylist attribute's type | within the type of the root element | within the document type for <root> documents | in the myNamespace namespace".

Note that the signature structure mirrors the Java class structure generated by XMLBeans when compiling the schema. In other words, if you were to compile a schema that included the preceding snippet, you would be able to access an instance of the schema with Java code like the following:

SchemaType sType = RootDocument.Root.MyList.Item.type;

Related Topics

Getting Started with XMLBeans