XML documents that use schema documents

An XML Schema is a data model for XML documents that uses a schema document (.xsd extension) to define the template (schema) of an XML document. Unlike a DTD, a schema document uses the same syntax as an XML document to describe the schema. The business object definitions that represent the schema of an XML document use information in the schema document to preserve and record the document's structure. This section provides the following information about deriving structure information for a business object definition from a schema document:

Requirements for business object definitions based on schema documents

To ensure that business object definitions that represent schema documents conform to the requirements of the XML data handler, use the guidelines in this section, which involve:

Business object structure for schema documents

A business object that is processed by the XML data handler using business object definitions based on schema documents must follow these rules:

An example schema document for an XML document is shown in Figure 18. The schema document is named Order, and it contains elements that correspond to an application Order entity. This sample schema document describes the same business object structure as the one that the sample DTD document described. Figure 13 shows the structure of a business object definition that might be created to correspond to an XML document associated with the Order schema document.

Figure 18. Sample XML schema document

<?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified">
 
        <xs:complexType name="AccessoryType">
                 <xs:sequence>
                         <xs:element ref="Quantity"/>
                         <xs:element ref="Type"/>
                 </xs:sequence>
                 <xs:attribute name="Name" type="xs:string" use="required"/>
         </xs:complexType>
         <xs:element name="Order">
                 <xs:complexType>
                         <xs:sequence>
                                 <xs:element name="Unit" type="UnitType" 
                     maxOccurs="unbounded"/>
                         </xs:sequence>
                 </xs:complexType>
         </xs:element>
         <xs:element name="PartNumber" type="xs:string"/>
         <xs:element name="Price" type="xs:string"/>
         <xs:element name="Quantity" type="xs:string"/>
         <xs:element name="Type" type="xs:string"/>
         <xs:complexType name="UnitType">
                 <xs:sequence>
                         <xs:element ref="PartNumber" minOccurs="0"/>
             <xs:element ref="Quantity"/>
             <xs:element ref="Price"/>
             <xs:element name="Accessory" type="AccessoryType" minOccurs="0"
                    maxOccurs="unbounded"/>
                 </xs:sequence>
     </xs:complexType>
 </xs:schema>
 
Required business object definitions for schema documents

To represent a schema document requires at least the two business object definitions described in Business object structure. For a schema document, these business object definitions have the following additional requirements:

Note:
For a list of general business object requirements, see Requirements for business object definitions.

Both these required business object definitions require business-object-level application-specific information that defines the target namespace and any component-name qualifications. For more information, see Business-object-level application-specific information.

The XML schema element in Figure 18 is as follows:

<?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified">
 

Figure 19 shows the top-level business object definition, TopLevel, which represents this schema element.

Figure 19. Sample top-level business object definition

[BusinessObjectDefinition]
 Name=TopLevel
 AppSpecificInfo=elem_fd=qualified;attr_fd=unqualified
 ...
 
   [Attribute]
    Name=XMLDeclaration
    Type=String
    AppSpecificInfo=type=pi;
    ...
    [End]
 
   [Attribute]
    Name=Order
    Type=TopLevel_Order
    AppSpecificInfo=elem_name=Order;
    ...
    [End]
 ...
 [End]
 

If the XML ODA generated the top-level business object definition in Figure 19, the following ODA configuration properties would have been set:

ODA configuration property Value of property
BOPrefix Not set
TopLevel "TopLevel"
Root "Order"
DoctypeorSchemaLocation true

For an example of a root-element business object definition, see Figure 24.

Regular business object definitions based on schema documents

A regular business object definition represents any of the following XML constructs:

In these types of business object definition, the business-object-level application-specific information does not require any special information. The attributes of a regular business object definition represent the elements defined within the XML complex type.

Note:
For complex types that contain a sequence group of child elements, each child element in the sequence group is represented as an attribute in the business object definition.

For example, suppose an XML element named Unit is defined as:

<xsd:element name="Unit">
     <xsd:complexType>
     ...
     </xsd:complexType>
 </element> 
 

The following business object definition represents the Unit element:

[BusinessObjectDefinition]
 Name = MyApp_Unit
 AppSpecificInfo =
    [Attribute]
    ...
 
Mixed business object definitions based on schema documents

A mixed business object definition represents a mixed XML element, one that contains mixed content of character data and other subelements. A schema document describes a mixed-type XML element as a complex type with the mixed attribute set to true, as follows:

<xsd:complexType mixed="true">
     <xsd:sequence>
         <xsd:element name="subElement1" type="subElementType"/>
         ...
     </xsd:sequence>
 </xsd:complexType>
 
Note:
Mixed business objects, as described in this section, are used for a repeating list of elements and character data. If your choice list does not contain any character data, use a wrapper business object as described in Qualified component names.

Because this complex type sets the mixed attribute to true, it can contain character data in addition to the one or more subelements it defines. If the mixed attribute is set to false, no character data is permitted in the complex type.

For example, Figure 20 shows a mixed-type XML element defined in a schema document.

Figure 20. Sample schema document for a mixed-type XML element

<xsd:complexType name="Cust" mixed="true">
     <xsd:sequence>
         <xsd:element name="Name"/>
         <xsd:element name="Address"/>
         <xsd:element name="Phone"/>
     </xsd:sequence>
 </xsd:complexType>
 

To represent a mixed-type XML element requires the following two business object definitions:

If the business object definition, MyApp_Cust, represents the Cust mixed-type element in Figure 20, its application-specific information is as follows:

[BusinessObjectDefinition]
 Name = MyApp_Cust
 AppSpecificInfo = type=MIXED;
  
    [Attribute]
    Name=Cust_wrapper1
    Type=MyApp_CustWrapper1
    Cardinality=n
    AppSpecificInfo=(Cust|Address|Phone)
    ...
    [End]
 
Wrapper business object definitions based on schema documents

A wrapper business object definition represents a repeating choice list. This type of business object definition is needed when an XML element has children that can appear in any order and be of any cardinality. A wrapper business object preserves the order and cardinality of the child elements in a particular XML document.

Note:
Wrapper business objects, as described in this section, are used for a repeating choice list that contains elements, not for character data. If your choice list contains any character data, use a mixed business object. For more information, see Mixed business object definitions based on schema documents.

A schema document can describe a choice-list XML element as a complex type that contains either of the following model groups:

To indicate cardinality, these model groups support occurrence constraints with the minOccurs and maxOccurs attributes. For more information, see Table 16.

As an example, the XML element definition in a schema document might be:

<xsd:element name="CUST">
     <xsd:complexType>
         <xsd:choice minOccurs="0" maxOccurs="unbounded">
             <xsd:element ref="U"/>
             <xsd:element ref="I"/>
             <xsd:element ref="B"/>
         </xsd:choice>
     </xsd:complexType>
 </xsd:element>
 

This element contains three subelements that are optional (although one subelement out of the list must occur) and that can appear in any order. Figure 14 shows an XML document of this type. Figure 16 shows the parent business object definition for this XML document. Figure 17 shows the wrapper business object definition.

Business object attribute properties for schema documents

When the business object definitions for an XML document are based on schema documents, the business object attribute properties have the restrictions discussed in Business object attribute properties. In addition, the schema-document syntax can determine the "required-ness" of a business object attribute. The "required-ness" is a combination of factors, including cardinality and whether the attribute is a key, that determines whether the XML data handler requires the attribute. If an attribute is required, its Required attribute property must be set to true.

The setting of the Required attribute property depends on the XML element and attribute specifications, as well as the settings of the Cardinality, Key, and Foreign Key attribute properties, as follows:

Application-specific information for XML compnents in schema documents

This section provides the following information on the application-specific information format for business object definitions based on schema documents:

Business-object-level application-specific information

The XML data handler uses the following types of business object definitions to represent the different kinds of root XML elements defined in a schema document. These types of business object definitions are distinguished by the application-specific information at the business object level.

Table 19. Tags for business-object-level application-specific information

Tag in
application-specific information
Description For more information
target_ns Specifies the target namespace of the schema document Schema namespaces
attr_fd Specifies whether attribute names are qualified or unqualified. Qualified component names
elem_fd Specifies whether the names of locally declared elements are qualified or unqualified. Qualified component names
Note:
Business-level application-specific information can also include the type=MIXED tag. For more information, see Mixed business object definitions based on schema documents.
Schema namespaces

Unlike DTDs, schema documents require definition of at least one namespace. A namespace provides a context for the names of elements, element types, and attributes within an XML document. A namespace is a Uniform Resource Identifier (URI), which includes HTTP, FTP, as well as other kinds of paths. Table 20 shows the namespaces that a schema document can declare to be able to resolve the references between schema components.

Table 20. XML namespaces

Namespace Description Name Common prefix
XML Schema Namespace Defines every component used in the XML Schema Definition Language (XSDL), such as element, schema, and simpleType.
http://www.w3.org/2001/
 XMLSchema
 
xsd, xs
XML Schema Instance Namespace Defines four attributes associated with the schema instance: type, nil, schemaLocation, noNamespaceSchemaLocation
http://www.w3.org/2001/
 XMLSchema-instance
 
xsi
User-defined namespace

Defines every component declared or defined by a global declaration (such as element, attribute, type, or group).

Note:
Locally declared elements may or may not use the target namespace. For more information, see Qualified component names.
User-defined User-defined
Note:
The XML ODA supports schema documents with multiple target namespaces.

Every schema document can declare one target namespace, which identifies the namespace to which global components (elements, attributes, types, or groups) belong, with the targetNamespace tag. If the schema element includes the targetNamespace tag, each business object definition generated for that schema document must contain the target_ns tag in its application-specific information to specify the target namespace declared for the XML document:

target_ns=URI address for target namespace
 

The target_ns tag must exist in the business-object-level application-specific information for all business object definitions, as follows:

Note:
Previous versions of the XML data handler expected the top-level business object definition to have attributes for the namespace prefixes and to use the appropriate type=defaultNS and type=xmlns tags in the attribute-level application-specific information. This mechanism for defining namespace prefixes has been replaced, although the XML data handler continues to support it for backward compatibility with existing business object definitions. New business object definitions should use the target_ns tag as described in this section. The XML ODA has been modified to use the target_ns tag.

For example, the schema document in Figure 21 defines the XML Schema Namespace (with the xsd prefix) and a target namespace (which is the default namespace).

Figure 21. The Schema1.xsd sample schema document

<?xml version="1.0" encoding="UTF-8"?>
 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.ibm.com/ns1" xmlns="http://www.ibm.com/ns1">
 
   <xsd:complexType name="TaxInfoType">
       <xsd:sequence>
          <xsd:element name="SSN" type="string">
          </xsd:element>
 
         <xsd:element name="State" type="string">
          </xsd:element>
       </xsd:sequence>
    </xsd:complexType>
 
   <xsd:element name="Customer">
       <xsd:complexType>
          <xsd:sequence>
             <xsd:element name="TaxInfo" type="TaxInfoType">
             </xsd:element>
 
            <xsd:element name="BillTo" type="xsd:string">
             </xsd:element>
          </xsd:sequence>
 
         <xsd:attribute name="Name" type="xsd:string">
          </xsd:attribute>
 
         <xsd:attribute name="ID" type="xsd:string">
          </xsd:attribute>
       </xsd:complexType>
    </xsd:element>
 </xsd:schema>
 

The XML ODA generates three business object definitions for this schema document: BOPrefix_TopLevel, BOPrefix_TopLevel_Customer, and BOPrefix_TopLevel_TaxInfoType (where BOPrefix and TopLevel are the values of these ODA configuration properties). All three of these business object definitions have the following in their business-object-level application-specific information:

target_ns=http://www.ibm.com/ns1;elem_fd=unqualified;attr_fd=unqualified
 
Note:
Because of the schema element in Figure 21 includes neither the elementFormDefault nor the attributeFormDefault attribute, this application-specific information includes the elem_fd and attr_fd tags set to unqualified. For more information, see Qualified component names.

One schema document can only define one target namespace. However, it can include elements and attributes defined in another schema document's target namespace by using the import element.

Figure 22 shows a schema document that is based on the Schema1.xsd document defined in Figure 21. This schema document imports the ns2 namespace, which declares the TaxInfoType complex type, the BillTo element, and the Name attribute.

Figure 22. Importing a target namespace

<?xml version "1.0" encoding="UTF-8"?>
 <xsd:schema smlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.com/ns1" xmlns="http://www.example.com/ns1"
    attributeFormDefault="qualified" elementFormDefault="qualified"
    xmlns:ns2="http://www.example.com/ns2">
 
   <xsd:import schemaLocation="Schema2.xsd" 
       namespace="http://www.example.com/ns2"/>
 
   <xsd:element name="Customer2">
       <xsd:complexType>
          <xsd:sequence>
             <xsd:element name="TaxInfo" type="ns2:TaxInfoType">
             </xsd:element>
 
            <xsd:element ref="ns2:BillTo">
             </xsd:element>
          </xsd:sequence>
 
         <xsd:attribute ref="ns2:Name">
          </xsd:attribute>
 
         <xsd:attribute name="ID" type="xsd:string">
          </xsd:attribute>
       </xsd:complexType>
    </xsd:element>
 </xsd:schema>
 

The business object definition for the root element, Customer2, must specify this alternate namespace for its attributes that represent the TaxInfo, BillTo, and Name XML components, as follows:

Figure 23 shows the schema document that defines the TaxInfoType, BillTo, and Name XML components in the ns2 namespace.

Figure 23. Defining the second namespace

<?xml version "1.0" encoding="UTF-8"?>
 <schema smlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.com/ns2"
    attributeFormDefault="qualified" elementFormDefault="qualified"
    xmlns:ns2="http://www.example.com/ns2">
 
   <complexType name="TaxInfoType">
       <sequence>
          <element name="SSN" type="string">
          </element>
          <element name="State" type="string">
          </element>
       </sequence>
    </complexType>
 
   <attribute name="Name" type="string"
    </attribute>
 
   <complexType name="AddressType">
       <sequence>
          <element name="Zip" type="string">
          </element>
          <element name="Street" type="string">
          </element>
       </sequence>
    </complexType>
 
   <element name="BillTo" type="ns2:AddressType">
    </element>
 </schema>
 

Figure 23 shows the business object definition for the Customer2 root element.

Figure 24. Sample root-element business object definition

[BusinessObjectDefinition]
 Name=TopLevel_Customer2
 AppSpecificInfo=target_ns=http://www.example.com/ns1;elem_fd=qualified;
    attr_fd=qualified
 ...
 
   [Attribute]
    Name=Name
    Type=String
    AppSpecificInfo=attr_name=Name;type=attribute;attr_ns=http://www.example.com/ns2
    ...
    [End]
 
   [Attribute]
    Name=ID
    Type=String
    AppSpecificInfo=attr_name=ID;type=attribute
    ...
    [End]
 
   [Attribute]
    Name=schemaLocation
    Type=String
    AppSpecificInfo=attr_name=schemaLocation;type=xsischemalocation
    ...
    [End]
 
   [Attribute]
    Name=TaxInfo
    Type=TopLevel_TaxInfoType
    AppSpecificInfo=elem_name=TaxInfo
    ...
    [End]
 
   [Attribute]
    Name=BillTo
    Type=TopLevel_AddressType
    AppSpecificInfo=elem_name=BillTo;elem_ns=http://www.example.com/ns2
    ...
    [End]
 ...
 [End]
 
Qualified component names

Within the XML document, names of components associated with a namespace are either qualified or unqualified, as follows:

The elementFormDefault attribute of the schema element specifies whether the names of locally declared elements are qualified. By default, locally declared elements are unqualified and belong to the default namespace. The value of the elementFormDefault attribute determines the value of the elem_fd tag in the business-object-level application-specific information, as Table 21 shows.

Table 21. Setting the elem_fd tag

Value of elementFormDefault Value of elem_fd tag
"unqualified"(or attribute is not specified at all) elem_fd=unqualified
"qualified" elem_fd=qualified

For example, the schema document in Figure 21 does not contain the elementFormDefault attribute in its schema element. Therefore, the business-object-level application-specific information in all the business object definitions for this schema document (BOPrefix_TopLevel, BOPrefix_TopLevel_Customer, and BOPrefix_TopLevel_TaxInfoType, where BOPrefix and TopLevel are the values of these ODA configuration properties) contains the tag:

elem_fd=unqualified
 
Note:
The business-object-level application-specific information for these three business object definitions would contain this same tag if the schema document's schema element included the attribute:
elementFormDefault="unqualified"
 

If an individual XML element includes the form attribute, this value of the form attribute overrides any setting of the elementFormDefault attribute.

The attributeFormDefault attribute of the schema element specifies whether the names of elements are qualified. By default, attribute names are unqualified and do not belong to any namespace. The value of the attributeFormDefault attribute determines the value of the attr_fd tag in the business-object level application-specific information in the same way as the value of the elementFormDefault attribute determines the value of the elem_fd tag, as Table 22 shows.

Table 22. Setting the attr_fd tag

Value of attributeFormDefault Value of elem_fd tag
"unqualified"(or attribute is not specified at all) attr_fd=unqualified
"qualified" attr_fd=qualified

For example, the schema document in Figure 21 does not contain the attributeFormDefault attribute in its schema element. Therefore, the business-object-level application-specific information in all the business object definitions for this schema document (BOPrefix_TopLevel, BOPrefix_TopLevel_Customer, and BOPrefix_TopLevel_TaxInfoType, where BOPrefix and TopLevel are the values of these ODA configuration properties) contains the tag:

attr_fd=unqualified
 
Note:
The business-object-level application-specific information for these three business object definitions would contain this same tag if the schema document's schema element included the attribute:
attributeFormDefault="unqualified"
 
Attribute application-specific information

The attribute of a business object definition can represent the following XML components:

Table 23 shows the tags for attribute-level application-specific information for these different XML components along with the sections in this manual that describe these tags in more detail.

Table 23. Tags for attribute application-specific information

Representation of business object attribute Application-specific information For more information
An XML element

elem_name=name of XML element

elem_ns=namespace for element's definition

elem_fd=value of form attribute

For XML elements
An XML element within a complex type

type=pcdata

For XML elements within a complex type
An attribute for an XML element

attr_name=name of XML attribute

type=attribute

attr_ns=namespace for attribute's definition

attr_fd=value of form attribute

For an XML attribute
An XML element or attribute whose content includes special characters

escape=true

For an XML element or attribute that contains special characters
A comment to be added to the XML document type=comment For an XML comment
A processing instruction type=pi For XML processing instructions
The schemaLocation or noNamespaceSchemaLocationattribute for an XML instance.

type=xsischemalocation

type=xsinoNSlocation

For XML schema locations
Note:
Attribute application-specific information can also include a tag of the form
( a | b | c ) to specify a multiple-cardinality attribute that represents a repeating choice. For more information, see Wrapper business object definitions based on schema documents.
For XML elements

If a business object attribute represents an XML element, its application-specific information must include the elem_name tag to identify the associated element:

elem_name=name of XML element
 
 

XML element names can contain special characters (such as periods and hyphens). However, the names of business object attributes cannot contain these special characters. Therefore, the name of the XML element must be specified in the elem_name tag. To name the business object attribute, the XML ODA removes any special characters in the XML element's name.

A business object attribute can represent an XML element in the following cases:

A business object attribute that represents an XML element can also include the following tags in its application-specific information:

For XML elements within a complex type

If a business object definition represents an XML complex type (complexType), the contents of this complex type are represented by simple (String) attributes within this business object definition. These business object attributes' application-specific information must include the elem_name tag to identify the name of the element.

Note:
For more information on this tag, see For XML elements.

Within an XML complex type, a business object attribute can represent the kinds of complex-type content shown in Table 24.

Table 24. Contents of an XML complex type

Type of complex-type element Description Attribute application-specific information
Simple XML element An element that contains only character content. It cannot contain any other elements or XML attributes. It can occur only within a complex type type=pcdata
Simple content Only character data (no element) type=pcdata;notag
XML element with attributes An element that contains both character data and some combination of subelements and attributes

None.

This type of XML element must be represented with a business object definition, not as a single business object attribute. For more information, see Regular business object definitions based on schema documents.

As an example of the use of the type=pcdata tag, the schema document in Figure 21 contains a definition for the TaxInfoType complex type, which contains only simple XML elements. The business object definition for the TaxInfoType XML complex type (BOPrefix_TopLevel_TaxInfoType, where BOPrefix and TopLevel are the values of the respectively named ODA configuration properties) would contain two attributes. Each attribute would have the name of the associated XML element in its application-specific information, as Figure 25 shows. Because this complex type contains only simple XML elements (no subelements or attributes), the corresponding business object attributes must also contain the type=pcdata tag in their application-specific information.

Figure 25. Sample business object definition for XML complex type with simple elements

[BusinessObjectDefinition]
 Name=BOPrefix_TopLevel_TaxInfoType
 AppSpecificInfo=target_ns=;elem_fd=unqualified;attr_fd=unqualified
 ...
 [End]
 
[Attribute]
 Name=SSN
 Type=String
 AppSpecificInfo=elem_name=SSN;type=pcdata
 ...
 [End]
 
[Attribute]
 Name=State
 Type=String
 AppSpecificInfo=elem_name=SSN;type=pcdata
 ...
 [End]
 

As an example of the notag keyword used in conjunction with the type=pcdata tag, suppose an XML element named Price is the PriceType complex type, which has only simple content; that i,s it contains only character data. In this case, the simpleContent element defined an attribute named Currency and requires data for Price:

<xsd:element name="Price" type="PriceType">
     <xsd:complexType name="PriceType">
         <xsd:simpleContent>
             <xsd:extension base="xsd:decimal">
                 <xsd:attribute name="Currency" type="xsd:NMTOKEN"/>
             </xsd:extension>
         </xsd:simpleContent>
     </xsd:complexType>
 </element>
 

The business object definition for the PriceType complex type contains an attribute to hold the character data associated with simple content. The application-specific information for this attribute must contain the following:

type=pcdata;notag
 

The notag keyword prevents the XML data handler from generating duplicate start tags (one for the business object definition and one for the attribute). The XML data handler creates an XML start and end tag for every business object attribute unless notag appears in the application-specific information for that attribute.

The Price child business object definition might look like this:

[BusinessObjectDefinition]
 Name = Price
 AppSpecificInfo =
  
 [Attribute]
 Name = Currency
 Type = String
 AppSpecificInfo = attr_name=Currency;type=attribute;
 ...
 [End]
  
 [Attribute]
 Name = Price
 Type = String
 AppSpecificInfo = elem_name=Price;type=pcdata;notag
 ...
 [End]
 

A business object attribute must exist to hold the Price data. The attribute for the Price data must specify notag in its application-specific information to prevent the data handler from creating a start and end tag for this attribute. In this case, the data handler does not generate a new XML element for the Price data but simply adds the data to the parent element.

In addition, the business object definition must contain another attribute must exist to hold the value of the Currency attribute. If the simple content contains attributes, the business object definition must also contain an attribute for each XML attribute. The attribute's application-specific information must include the type=attribute tag. For more information, see For an XML attribute.

For an XML attribute

When a business object definition represents an XML element or complex type, any attributes that the schema document declares for this element are represented as attributes within the business object definition. When a business object attribute represents an attribute of an XML element, its application-specific information must include the following tags:

Note:
For more information on these tags, see For an XML attribute. For an example of the use of the type=attribute tag, see For XML elements within a complex type.

A business object attribute that represents an XML attribute can also include the following tags in its application-specific information:

For an XML element or attribute that contains special characters

Business object attributes representing XML elements or XML attributes that include special characters in their content require escape processing by the XML data handler. To notify the data handler of the need to perform escape processing, the business object attribute's application-specific information must contain the following tag:

escape=true
 

The steps to specify escape processing for an XML document that uses a schema document to describe its schema are the same as to specify escape processing for an XML document that uses a DTD to describe its schema. For more information, see For an XML element or attribute that contains special characters.

For an XML comment

When the XML data handler converts a business object to an XML document, you can specify that it add the XML comments to the XML document by including the following tag in an attribute's application-specific information:


 type=comment
 

The XML ODA does not automatically generate business object attributes for XML comments. You must manually add these attributes. The steps to add comments to an XML document described by a schema document are the same as to define a comment for an XML document that is described by a DTD. For more information, see For an XML comment.

For XML processing instructions

If the XML document contains XML processing instructions, some business object definition associated with the schema document must contain an attribute to hold the processing value. The application-specific information of this attribute must contain the following type tag:

type=pi
 
 

For example, when the XML data handler converts an XML document to a business object, it puts the XML version in a special attribute of the top-level business object definition called XMLDeclaration. The top-level business object in Figure 19 shows the XMLDeclaration attribute within the TopLevel_Customer business object definition. For more information about the type=pi tag, see For XML processing instructions.

For XML schema locations

XML documents that refer to schema locations for their schema documents must include the following information:

For example, suppose the XML document has the namespace declaration in Figure 26.

Figure 26. Sample schema-location definition in an XML document

<order xmlns="http://sampleDoc.org.ord"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://www.example.com/order order.xsd">
    ...
 /<order>
 

The schema document might have the following namespace declaration, which defines a target namespace:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://www.example.com/order"
      targetNamespace="http://www.example.com/order">
 

For the business object that represents this XML document to be able to hold the information in the schemaLocation attribute, its business object definition must provide an attribute for this schema-location information. In the root-element business object definition, this schema-location information is represented as follows:

The root-element business object definition for the schema document that represents this XML document includes the following attributes for the schema location:

[Attribute]
 Name=schemaLocation
 Type=String
 AppSpecificInfo=type=xsischemalocation;
 
Note:
When an attribute represents the schemaLocation or noNamespaceSchemaLocation XML attribute, it does not require the type=attribute tag in its application-specific information.

The XML ODA determines whether to generate a schemaLocation or noNamespaceSchemaLocation attribute in the top-level business object based on the value of its DoctypeorSchemaLocation ODA configuration property.

Creating business object definitions from schema documents

A schema document describes and constrains the content of an XML document. Therefore, the schema document is very useful for obtaining information needed for the business object definition. To translate the structure information in the schema document to a business object definition, you can use the XML Object Discovery Agent (ODA). For information on XML ODA, see Using an XML ODA to create business object definitions.

Supported schema-document structures

The XML ODA maps element declaration in a schema to an attribute in the business object definition. The type of the business-object attribute depends on the type specified in the XML element declaration. A simple type maps to a String Java type. Complex types map to a business object definition.

The XML ODA supports structures of a schema document including:

Unsupported schema-document structures

The XML ODA is capable of processing most schema documents. However, it does not support the following schema-document structures:

Copyright IBM Corp. 2003