Working with Schemas

An IS schema is a “free-standing” element in Package Navigator view that acts as the blueprint or model against which you validate an XML document. The IS schema provides a formal description of the structure and content for a valid instance document (the XML document). The formal description is created through the specification of constraints. An IS schema can contain the following types of constraints:

  • Structural constraints in an IS schema describe the elements, attributes, and types that appear in a valid instance document. For example, an IS schema for a purchase order might specify that a valid <lineItem> element must consist of the <itemNumber>, <size>, <color>, <quantity>, and <unitPrice> elements in that order.
  • Content constraints in an IS schema describe the type of information that elements and attributes can contain in a valid instance document. For example, the <quantity> element might be required to contain a value that is a positive integer.

During data validation, Designer compares the elements and attributes in the instance document with the structural and content constraints described for those elements and attributes in the IS schema. Designer considers the instance document to be valid when it complies with the structural and content constraints described in the IS schema.

You can create IS schemas from an XML schema, a DTD (Document Type Definition), or an XML document that references an existing DTD.

What Does an IS Schema Look Like?

The appearance and content of an IS schema depends on whether you generate an IS schema from an XML schema or a DTD. For example, if you create an IS schema from an XML schema, the resulting IS schema displays type definitions, element declarations, and attribute declarations. If you create an IS schema from a DTD, the resulting IS schema displays element type declarations.

When you select an IS schema in Package Navigator view, Designer displays the contents of the IS schema in the editor. The schema editor is divided into two areas: the Schema browser on the left and the Component Details on the right. Above these areas, the editor identifies the target namespace for the IS schema.

Figure 1. Schema editor

Schema Browser

The Schema browser displays the components of an IS schema in a format that mirrors the structure and content of the source file. The Schema browser groups the global element declarations, attribute declarations, simple type definitions, and complex type definitions from the source file under the top-level headings ELEMENTS, ATTRIBUTES, SIMPLE TYPES, and COMPLEX TYPES. For example, the ELEMENTS heading contains all of the global element declarations from the XML schema or the DTD.

If the source file does not contain one of these global components, the corresponding heading is absent. For example, if you create an IS schema from an XML schema that does not contain any global attribute declarations, the Schema browser does not display the ATTRIBUTES heading. An IS schema created from a DTD never displays the SIMPLE TYPES or COMPLEX TYPES headings because DTDs do not contain type definitions.

Note: A DTD does contain attribute declarations. However, the Schema browser does not display the ATTRIBUTES heading for IS schemas generated from DTDs. This is because an attribute declaration in a DTD associates the attribute with an element type. Accordingly, the Schema browser displays attributes as children of the element type declaration to which they are assigned.

The Schema browser uses unique symbols to represent the components of the IS schema. Each of these symbols relates to a component of an XML schema or a DTD. The following table identifies the symbol for each component that can appear in an IS schema.

Note: In the following table, global refers to elements, attributes, and types declared or defined as immediate children of the <schema> element in an XML schema. All element type declarations in a DTD are considered global declarations.
Symbol Description
ELEMENTS. Used to group together the global element declarations in an IS schema. This symbol and category name do not correspond to a component in an XML Schema definition or a DTD.
Element declaration. An element declaration associates an element name with a type definition. This symbol corresponds to the <element> declaration in an XML schema definition and the ELEMENT declaration in a DTD.
Element reference. An element reference is a reference from an element declaration in a content specification to a globally declared element.

In an IS schema generated from an XML schema, this symbol corresponds to the ref="globalElementName" attribute in an <element> declaration.

In an IS schema generated from DTD, this symbol appears next to an element that is a child of another element. The parent element has only element content.

Any element declaration. In XML schema definition, an <any> element declaration is a wildcard declaration used as a placeholder for one or more undeclared elements in an instance document.

In a DTD, an element declared to be of type ANY can contain any well-formed XML. This symbol corresponds to an element declared to be of type ANY.

Because an <any> element declaration does not have a name, the Schema browser uses 'Any' as the name of the element.

ATTRIBUTES. Used to group together the global attribute declarations in an IS schema. This symbol and category name do not correspond to a component in an XML Schema definition or a DTD.
Attribute declaration. An attribute declaration associates an attribute name with a simple type definition. This symbol corresponds to the XML schema <attribute> declaration or the attribute in a DTD ATTLIST declaration.
Attribute reference. An attribute reference is a reference from a complex type definition to a globally declared attribute. This symbol corresponds to the ref="globalAttributeName" attribute in an attribute declaration.

DTDs do not have attribute references. Consequently, attribute references do not appear in IS schemas generated from DTDs.

Any attribute declaration. An any attribute declaration is a wildcard declaration used as a placeholder for undeclared attributes in an instance document. This symbol corresponds to the <anyAttribute> declaration in an XML schema definition.

Because an <anyAttribute> declaration does not specify an attribute name, the Schema browser uses 'Any' as the name of the attribute.

SIMPLE TYPES. Used to group together the global simple type definitions in an IS schema. This symbol and category name do not correspond to a component in an XML Schema definition or a DTD.
Simple type definition. A simple type definition specifies the data type for a text-only element or an attribute. Unlike complex type definitions, simple type definitions cannot carry attributes. This symbol corresponds to the <simpleType> element in an XML schema definition.

If the simple type definition is unnamed (an anonymous type), the Schema browser displays 'Anonymous' as the name of the simple type definition.

COMPLEX TYPES. Used to group together the global complex type definitions in an IS schema. This symbol and category name do not correspond to a component in an XML Schema definition or a DTD.
Complex type definition. A complex type definition defines the structure and content for elements of complex type. (Elements of complex type can contain child elements and carry attributes.) This symbol corresponds to the <complexType> element in an XML schema definition.

If the complex type definition is unnamed (an anonymous type), the Schema browser displays 'Anonymous' as the name of the complex type definition.

Sequence content model. A sequence content model specifies that the child elements in the instance document must appear in the same order in which they are declared in the content model. This symbol corresponds to the <sequence> compositor in an XML schema or a sequence list in an element type declaration in a DTD.
Choice content model. A choice content model specifies that only one of the child elements in the content model can appear in the instance document. This symbol corresponds to the <choice> compositor in an XML schema definition or a choice list in a DTD element type declaration.
All content model. An all content model specifies that child elements can appear once, or not at all, and in any order in the instance document. This symbol corresponds to the <all> compositor in an XML schema definition.
Mixed content. Elements that contain mixed content allow character data to be interspersed with child elements. This symbol corresponds to the mixed="true" attribute in an XML schema complex type definition or a DTD element list in which the first item is #PCDATA.
Empty content. In an XML schema, an element has empty content when its associated complex type definition does not contain any element declarations. An element with empty content may still carry attributes.

In a DTD, an element has empty content when it is declared to be of type EMPTY.

Component Details

The Component Details area displays information that you use to examine and edit the selected component in the Schema browser. The contents of Component Details varies depending on what component you select. For example, when you select a globally declared element of complex type, the Component Details looks like the following:

Figure 2. Schema editor for an element declaration

When you select a simple type definition, the Component Details looks like the following:

Figure 3. Schema editor for a simple type definition

Creating an IS Schema

About this task

You can create IS schemas from XML schema definitions, DTDs, and XML documents that reference an existing DTD. The resulting IS schema contains all of the defined types, declared elements, and declared attributes from the source file.

You can create an IS schema from an XML Schema definition in CentraSite. To do so, Designer must be configured to connect to CentraSite.

To create an IS schema

Procedure

  1. In the Package Navigator view of the Service Development perspective, click File > New > Schema.
  2. In the New Schema dialog box, select the folder in which you want to save the IS document type.
  3. In the Element Name field, type a name for the IS document type using any combination of letters, numbers, and/or the underscore character. For information about restricted characters, see About Element Names.
  4. Click Next.
  5. On the Select the Source Type panel, do one of the following:
    Select... To...
    XML Create an IS schema based on an existing DTD referenced by an XML document.
    Note: You can create an IS schema from an XML document only if the XML document references an existing DTD.
    DTD Create an IS schema based on a DTD.
    XML Schema Create an IS schema based on an XML schema definition.
  6. On the Select a Source Location panel, under Source location, do one of the following to specify the source file for the IS schema:
    • To use an XML schema definition in CentraSite as the source, select CentraSite.
    • To use an XML document, DTD, or XML schema definition that resides on the Internet as the source, select File/URL. Then, type the URL of the resource. (The URL you specify must begin with http: or https:.)
    • To use an XML document, DTD, or XML Schema definition that resides on your local file system as the source, select File/URL. Then, type in the path and file name, or click the Browse button to navigate to and select the file.
  7. Click Next.
  8. If you selected CentraSite as the source, under Select XML Schema from CentraSite, select the XML Schema definition in CentraSite that you want to use to create the IS schema. Click Next.

    If Designer is not configured to connect to CentraSite, Designer displays the CentraSite > Connections preference page and prompts you to configure a connection to CentraSite.

    Note: You can also create an IS schema from an XML Schema definition asset in CentraSite by dragging and dropping the schema asset from the Registry Explorer view into Package Navigator view.
  9. If the source file is an XML Schema definition, on the Select Schema Domain panel, under Schema domain, specify the schema domain to which any generated IS schemas will belong. Do one of the following:
    • To add the IS schema to the default schema domain, select Use default schema domain.
    • To add the IS schemas to a specified schema domain, select Use specified schema domain and provide the name of the schema domain in the text box. A valid schema domain name is any combination of letters, numbers, and/or the underscore character. For information about restricted characters, see About Element Names.

    For more information about schema domains, see About Schema Domains.

  10. If the source file is an XML Schema definition and you want Integration Server to use the Xerces Java parser to validate the XML Schema definition, select the Validate schema using Xerces check box.
    Note: Integration Server automatically uses an internal schema parser to validate the XML Schema definition. However, the Xerces Java parser provides stricter validation than theIntegration Server internal schema parser. As a result, some schemas that the internal schema parser considers to be valid might be considered invalid by the Xerces Java parser.
  11. Click Finish.

    Designer generates the IS schema using the document you specified and displays it in the editor

Results

Notes:
  • Integration Server uses the internal schema parser to validate an XML schema definition. If you selected the Validate schema using Xerces check box, Integration Server also uses the Xerces Java parser to validate the XML Schema definition. With either parser, if the XML Schema does not conform syntactically to the schema for XML Schemas defined in W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures (which is located at https://www.w3.org/TR/xmlschema11-1/), Integration Server does not create an IS schema. Instead, Integration Server displays an error message that lists the number, title, location, and description of the validation errors within the XML Schema definition. If only warnings occur, Designer generates the IS schema.
    Note: Integration Server uses Xerces Java parser version Xerces-J 2.12.1-xml-schema-1.1. Limitations for this version are listed at http://xerces.apache.org/xerces2-j/xml-schema.html.
  • When validating XML schema definitions, Integration Server uses the Perl5 regular expression compiler instead of the XML regular expression syntax defined by the World Wide Web Consortium for the XML Schema standard. As a result, in XML schema definitions consumed by Integration Server, the pattern constraining facet must use valid Perl regular expression syntax. If the supplied pattern does not use proper Perl regular expression syntax, Integration Server considers the pattern to be invalid.
    Note: If the watt.core.datatype.usejavaregex configuration parameter is set to true, Integration Server uses the Java regular expression compiler instead of the Perl5 regular expression compiler. When the parameter is true, the pattern constraining facet in XML schema definitions must use valid syntax as defined by the Java regular expression.
  • Integration Server does not create IS schemas from an XML schema definition (XSD) if the XSD contains a type definition derived by extension and that type definition contains a direct or indirect reference to itself. If Integration Server encounters a type definition that contains a recursive extension while creating an IS schema from an XSD, Integration Server throws a StackOverflowError and does not continue creating the IS schema.
  • You might receive errors or warnings when creating an IS schema from a DTD. If one or more errors occur, Designer does not generate an IS schema. If only warnings occur, Designer generates the IS schema.
  • When creating an IS schema from an XML Schema definition that imports multiple schemas from the same target namespace, Integration Server throws Xerces validation errors indicating that the element declaration, attribute declaration, or type definition cannot be found. The Xerces Java parser honors the first <import> and ignores the others. To work around this issue, you can do one of the following:
    • Combine the schemas from the same target namespace into a single XML Schema definition. Then change the XML schema definition to import the merged schema only.
    • When creating the IS schema, clear the Validate schema using Xerces check box to disable schema validation by the Xerces Java parser. When generating the IS schema, Integration Server will not use the Xerces Java parser to validate the schemas associated with the XML Schema definition.

Creating an IS Schema from XML Schemas that Reference Other Schemas

A schema author can insert the elements, attributes, and type definitions from another schema into the schema they are creating. A schema author might do this to break up a large XML schema into several small, more reusable XML schemas. When you generate an IS schema from an XML schema that references another schema, Integration Server either includes all of the schema components in a single IS schema, creates multiple IS schemas, or creates no IS schema at all. The behavior of the Integration Server depends on the mechanism the source XML schema uses to reference the other schema. The following mechanisms can be used to reference an external schema:

  • Include. When you generate an IS schema from an XML schema that uses <include> to include the contents of an external schema in the same namespace, the resulting IS schema contains all of the defined types, declared elements, and declared attributes from the source schema and the external schema. If the including, or root, XML schema references an external schema that does not contain a target namespace declaration, the external schema assumes the target namespace of the root schema.
  • Import. When you generate an IS schema from an XML schema that contains an <import> element to import the contents of an external schema in a different namespace, Integration Server creates one IS schema per namespace. For example, if the source XML schema imports two XML schemas from the same namespace, Integration Server creates an IS schema for the source XML schema and then a second IS schema that includes the components from the two imported XML schemas. Integration Server assigns each imported schema the name that you specify and appends an underscore and a number to each name. For example, if you create an IS schema named “mySchema” from mySchema.xsd, Integration Server generates an IS schema named “mySchema_2” for the imported XML schema.
  • Redefine. Schema authors can also use <redefine> to include and then redefine type definitions, model groups, and attribute groups from an external XML schema in the same namespace. Integration Server creates one IS schema per namespace.

About Editing Simple Type Definitions

You can modify a simple type definition in an IS schema without editing the source XML schema definition. You edit a simple type by adding or changing the value of one or more constraining facets applied to the simple type. For example, you can modify a simple type by adding an enumerated value, a pattern constraint, or changing the length constraint. Editing the simple type through Designer is an alternative to editing the source XML schema definition and regenerating the IS schema.

You can edit any of the globally defined simple types (those that appear under the SIMPLE TYPES heading) or anonymous simple types (those defined as part of an element or attribute declaration.) A named simple type that appears as a child of an element or attribute in the Schema browser cannot be edited. (These simple types are global simple types used to define the element or attribute they appear under.) The following illustration identifies the simple type definitions that you can and cannot edit.

Figure 4. Editable simple type definitions in an IS schema

You can edit any of the constraining facet values that appear in the Component Details when you select an editable simple type definition in the Schema browser. The constraining facets displayed in the Component Details depend on the primitive type from which the simple type was derived. For example, if the simple type definition is derived from string, the Component Details displays the enumeration, length, minLength, maxLength, pattern, and whiteSpace facets. The Component Details only displays constraining facet values set in the simple type definition. It does not display constraining facet values the simple type definition inherited from the simple types from which it was derived.

You can view the constraining facet values set in the type definitions from which a simple type was derived by clicking Base Constraints. Base constraints are the constraining facet values set in all the type definitions from which a simple type is derived—from the primitive type to the immediate parent type. These constraint values represent the cumulative facet values for the simple type.

When you edit the constraining facets for a simple type definition, you can only make the constraining facets more restrictive. The applied constraining facets cannot become less restrictive. For example, if the length value is applied to the simple type, the maxLength or minLength values cannot be set because the maxLength and minLength facets are less restrictive than length.

Tip: You can create a custom simple type to apply to a field as a content type constraint. For information about creating a custom simple type, see Customizing a String Content Type. For information about applying constraints to fields, see Applying Constraints to a Variable.

Editing a Simple Type Definition

About this task

When modifying a simple type definition, keep the following points in mind:
  • Changes to a simple type definition affect the elements and attributes for which the simple type is the defined type. For example, if the attribute partNum is defined to be of type SKU, changes to the SKU simple type definition affect the partNum attribute.
  • Changes to a global simple type definition in an IS schema do not affect simple types derived from the global simple type; that is, the changes are not propagated to the derived types in the IS schema.
  • Simple types in an IS schema can be used as content constraints for fields in pipeline validation. Consequently, changes to a simple type also affect every field to which the simple type is applied as a content constraint.
  • Changes to a simple type definition are saved in the IS schema. If you regenerate the IS schema from the XML schema definition, your changes will be overwritten.
  • When you edit the constraining facets applied to a simple type definition, you can only make the constraining facet values more restrictive. The constraining facets cannot become less restrictive.
  • If you want to edit complex type definitions, attribute declarations, element declarations, or the structure of the schema, you need to edit the XML schema and then regenerate the IS schema.
  • For an IS schema from a source file such as an XML schema definition or a WSDL document Designer displays the location of the source file in the Source URI property. Designer also sets the Linked to source property to true which prevents any editing of the simple type definitions in the IS schema. To edit the simple type definitions, you first need to make the IS schema editable by breaking the link to the source. For information about allowing editing of elements derived from a source, see Allowing Editing of Derived Elements. However, Software AG does not recommend editing the contents of IS schemas created from WSDL documents.
  • For more information about constraining facets, see the W3C specification XML Schema Part 2: Datatypes.

To edit a simple type definition

Procedure

  1. In the Package Navigator view of the Service Development perspective, open the IS schema that contains the simple type that you want to edit.
  2. In the Schema Browser, select the simple type definition that you want to edit.
  3. In Component Details, specify the constraining facets that you want to apply to the simple type definition.
  4. Click File > Save.

About Schema Domains

Each IS schema on Integration Server belongs to a schema domain. A schema domain is a named collection of IS schemas.

Within each schema domain, the schema components such as element declarations, attribute declarations, type definitions for an XML namespaces must be unique. However, more than one schema domain can contain the same schema components for an XML namespace. This allows Integration Server to maintain multiple IS schemas for the same XML namespace.

If you want to maintain alternate definitions of schema components for an XML namespaces, assign the IS schemas that contain those components to different schema domains.

Integration Server contains a default schema domain in which any IS schemas created prior to version 8.0 reside. You can place new schemas in the default schema domain or you can specify a different schema domain. A schema domain name is any string that is a valid name of an element in Integration Server.

When Integration Server consumes a WSDL document to create a web service descriptor, Integration Server places any generated IS schemas in a unique schema domain for that web service descriptor. Integration Server uses a combination of alphanumeric characters as the schema domain name.

When Integration Server creates an IS document type from an e-form template, Integration Server places any generated IS schemas in a unique schema domain whose name is based on the path to and name of the e-form template.

XML Schema 1.0 Support in Integration Server

Integration Server supports the majority of the features available in XML Schema 1.0. However, Integration Server does not support the following identity-constraint definition components:

  • key
  • keyref
  • unique

If just the internal schema parser is used when creating an IS schema from an XML Schema definition that contains the above components, Integration Server skips the above components during compilation. If the Xerces schema parser is used as well, Xerces validates the components but Integration Server skips them during compilation. In both cases, the unsupported components will not be used during validation.

XML Schema 1.1 Support in Integration Server

XML Schema 1.1 is a superset of XML Schema 1.0. New capabilities available in XML Schema 1.1 fall into two general categories:
  • Relaxed schema restrictions such that a schema invalid in XML Schema 1.0 is valid in XML Schema 1.1. For example, the all content model can have a maxOccurs attribute with a value greater than 1 and may also contain wildcards.
  • New schema components such as assertion or openContent.

Integration Server provides a subset of support for the new features in XML Schema 1.1.

Designer can display the new, supported XML Schema 1.1 features that are a result of relaxed schema constraints. For example, Designer can display wildcards for an all content model. However, Designer does not display new, supported components such as the assertion facet.

Note: XML Schema 1.1 is not supported on AIX. The Xerces library in AIX supports XML Schema 1.0 only. Attempts to use XML Schema 1.1 features on an Integration Server running on AIX results in schema syntax errors and the schema does not compile.

Supported Features from XML Schema 1.1

Integration Server supports the following features added in XML Schema 1.1:

  • Enhancements to the all content model
    • maxOccurs > 1
    • Wildcards
    • Nested all content model references
  • New simple types:
    • dateTimeStamp
    • dayTimeDuration
    • yearMonthDuration
  • New constraining facets:
    • assertion
    • explicitTimeZone
  • New attributes on existing components:
    • defultAttributes on schema
    • xpathDefaultNamespace on schema
    • defaultAttributesApply on complexType
  • New attributes on all components for conditional composition:
    • typeUnavailable
    • facetUnavailable
  • New attributes on the any and anyAttribute wildcards:
    • notQName
    • notNamespace

Unsupported Features from XML Schema 1.1

Integration Server does not support the following features added in XML Schema 1.1:

  • New components:
    • alternative
    • assert
    • defaultOpenContent
    • openContent
    • override
  • New attributes:
    • inheritable on attribute
    • targetNamespace on a local attribute declaration
    • targetNamespace on a local element declaration

When creating an IS schema or an IS document type from an XML schema definition that uses an XML Schema 1.1 feature that Integration Server does not support, Designer displays the following warning message:

[ISC.0082.9726] Schema 1.1 feature not currently implemented: featureName

The preceding message is a warning message and does not prevent Integration Server from compiling creating the IS schema. However, the IS schema will not contain the unsupported feature.