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:
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:
A business object that is processed by the XML data handler using business object definitions based on schema documents must follow these rules:
For more information, see Required business object definitions for schema documents.
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>
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:
This attribute must has the type=pi tag in its application-specific information. For more information, see For XML processing instructions.
As described in Business object structure, this attribute must have as its type a single-cardinality business object, whose type is the business object definition for the root element. The application-specific information must list the name of this element with the elem_name tag. For more information, see For XML elements.
Whether the XML ODA generates a schemaLocation attribute in the top-level business object definition depends on the setting of its DocTypeOrSchemaLocation configuration property. For more information, see For XML schema locations.
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 26.
A regular business object definition represents any of the following XML constructs:
Each child element in the sequence group is represented as an attribute in the business object definition. For more information, see For XML elements within a complex type.
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.
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] ...
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>
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:
This parent business object definition contains a single attribute that represents a multiple-cardinality business object array. This attribute has as its type the business object definition for the associated wrapper business object. The parent business object definition includes the following application-specific information:
(mixedTypeElement|subElement1|...|subElementN)
where:
The pipe (|) character must separate each of the subelements and the entire tag must be enclosed in parentheses.
The wrapper business object definition contains attributes for the mixed data:
For more information on the type=pcdata tag, see For XML elements within a complex type.
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]
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.
A schema document can describe a choice-list XML element as a complex type that contains either of the following model groups:
<xsd:complexType> <xsd:choice> ... </choice> </complexType>
To represent an XML element with a complex type that contains a choice group, the XML data handler expects the same hierarchical business object definition that it does for a choice-list XML element defined in a DTD:
These business object definitions contain business-object-level application-specific information in the same format as the choice-list XML element for a DTD. For more information, see Wrapper business object definitions based on DTDs.
<xsd:complexType> <xsd:all> ... </xsd:all> </xsd:complexType>
To represent an XML element with a complex type that contains an all group, the XML data handler expects a hierarchical business object definition with the following business object definitions:
These business object definitions contain business-object-level application-specific information in the same format as the choice-list XML element for a DTD. For more information, see Wrapper business object definitions based on DTDs.
To indicate cardinality, these model groups support occurrence constraints with the minOccurs and maxOccurs attributes. For more information, see Table 20.
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.
Type substitution enables derived types to appear in place of their base types in individual XML document instances. When type substitution occurs, an element conforming to a declaration with one data type can have any data type that either extends or restricts it. In the following schema definition, ShirtType and HatType are derived types of the basic ProductType:
Figure 21. Sample schema with type substitution
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="items" type="ItemsType"/> <xsd:complexType name="ItemsType"> <xsd:sequence> <xsd:element ref="product" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="product" type="ProductType"/> <xsd:complexType name="ProductType"> <xsd:sequence> <xsd:element name="number" type="xsd:string"/> <xsd:element name="name" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ShirtType"> <xsd:complexContent> <xsd:extension base="ProductType"> <xsd:sequence> <xsd:element name="size" type="xsd:string"/> <xsd:element name="color" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="HatType"> <xsd:complexContent> <xsd:extension base="ProductType"> <xsd:sequence> <xsd:element name="size" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema>
Based on the schema above, the following XML document is valid:
Figure 22. Derived types in an XML document
<items xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <product> <number>999</number> <name>Special Seasonal</name> </product> <product xsi:type="ShirtType"> <number>557</number> <name>Short-Sleeved Linen Blouse</name> <size>M</size> <color>blue</color> </product> <product xsi:type="HatType"> <number>443</number> <name>Four-Gallon Hat</name> <size>L</size> </product> </items>
Wherever ProductType occurs, its derived types, ShirtType and HatType,
indicated by the xsi:type attribute, can appear instead. To
represent XML documents in which type substitution occurs, the XML data
handler creates a wrapper business object as a child attribute of the XML
document. This wrapper business object has child attributes
corresponding to the compex type (ProductType in Figure 21) and its derived types (ShirtType and HatType). Table 18 and Table 19 show the business object
definitions that would be generated from the XML schema above.
Table 18. Business object definitions for ItemsType
Attribute Name | Type | Cardinality | ASI |
---|---|---|---|
Product | ProductTypeWrapper | N | (product);typeSub=true |
Table 19. Business object definitions for ProductTypeWrapper
Attribute | Type | Cardinality | ASI |
---|---|---|---|
ProductType | ProductType | 1 | Elem_name=product;
xsiType=ProductType |
ShirtType | ShirtType | 1 | Elem_name=product;
xsiType=ShirtType; |
HatType | HatType | 1 | Elem_name=product;
xsiType=HatType; |
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:
Table 20. Cardinality and "Required-ness" for a schema document
Schema fragment occurrence indicator | Cardinality | Required |
---|---|---|
None specified | 1 | Yes |
maxOccurs > 1 | N | Yes |
maxOccurs = "unbounded" | N | Yes |
minOccurs=0 | No effect | No |
minOccurs>1 | N | Yes |
Table 21. "Required-ness" for a schema document
Schema fragment occurrence attribute: use | Cardinality | Required |
---|---|---|
None specified | No effect | No |
use=required | No effect | Yes |
Table 22. Keys and "Required-ness" for a schema document
Schema fragment attribute: id | Key | Required | Comment |
---|---|---|---|
id=ID | Yes | No |
|
This section provides the following information on the application-specific information format for business object definitions based on schema documents:
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 23. 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 |
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 24 shows the namespaces that a schema document can declare to
be able to resolve the references between schema components.
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).
| User-defined | User-defined |
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:
For example, the schema document in Figure 23 defines the XML Schema Namespace (with the xsd prefix) and a target namespace (which is the default namespace).
Figure 23. 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
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 24 shows a schema document that is based on the Schema1.xsd document defined in Figure 23. This schema document imports the ns2 namespace, which declares the TaxInfoType complex type, the BillTo element, and the Name attribute.
Figure 24. Importing a target namespace
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/ns2" xmlns:ns2="http://www.example.com/ns2"> <xsd:complexType name="TaxInfoType"> <xsd:sequence> <xsd:element name="SSN" type="xsd:string"/> <xsd:element name="State" type="xsd:string"/> </xsd:sequence> </xsd:complexType>
<xsd:attribute name="Name" type="xsd:string"></xsd:attribute>
<xsd:complexType name="AddressType"> <xsd:sequence> <xsd:element name="Zip" type="xsd:string"> </xsd:element> <xsd:element name="Street" type="xsd:string"> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:element name="BillTo" type="ns2:AddressType"> </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 25 shows the schema document that defines the TaxInfoType, BillTo, and Name XML components in the ns2 namespace.
Figure 25. 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 25 shows the business object definition for the Customer2 root element.
Figure 26. 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]
Within the XML document, names of components associated with a namespace are either qualified or unqualified, as follows:
You can assign a prefix to one or more namespaces. You declare a namespace's prefix with the xmlns:prefix tag, where prefix is the declared prefix. In the component definition within the schema document, these component names are qualified because they have a prefix prepended to the component name (prefix:componentName).
The default namespace specifies the namespace to associate with components that do not include a prefix in their component names. You declare the default namespace with the xmlns tag.
For the XML data handler to correctly handle XML-to-business-object conversion, the namespaces for the XML document and the schema document must match, 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 25 shows.
Table 25. 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 23 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
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 26 shows.
Table 26. 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 23 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
attributeFormDefault="unqualified"
The attribute of a business object definition can represent the following XML components:
Table 27 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 27. Tags for attribute application-specific information
Representation of business object attribute | Application-specific information | For more information |
---|---|---|
An XML element | For XML elements | |
An XML element within a complex type | For XML elements within a complex type | |
An attribute for an XML element |
attr_name=name of XML attribute
attr_ns=namespace for attribute's definition
| For an XML attribute |
An XML element or attribute whose content includes special characters | 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. |
| For XML schema locations |
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:
In this case, the business object attribute is a complex attribute whose data type is the business object definition that represents the XML complex type. Its elem_name tag (in the attribute's application-specific information) contains the name of the XML element (or complex type).
In this case, the business object attribute is a simple attribute of type String. Its application-specific information includes the elem_tag (which contains the name of the XML element within the complex type) and the type=pcdata tag. For more information, see For XML elements within a complex type.
A business object attribute that represents an XML element can also include the following tags in its application-specific information:
For example, suppose a locally declared XML element has the following definition:
<xsd:element ref="Name" form="qualified"></xsd:element>
Its associated business object attribute would have the following format:
[Attribute] Name=Name Type=String AppSpecificInfo=elem_name=Name;elem_fd=qualified; ...
If an XML element does not specify the form attribute, the value of the elementFormDefault attribute (on the schema element) determines whether element names are qualified. For more information, see Qualified component names.
For example, suppose an XML element within a complex type has the following definition:
<xsd:element ref="ns2:BillTo"></xsd:element>
Its associated business object attribute would have the following format:
[Attribute] Name=BillTo Type=String AppSpecificInfo=elem_name=BillTo;elem_ns=http:/www.imb.com/ns2; ...
For a complete example of a schema document that includes XML elements defined in a second namespace, see Schema namespaces.
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.
Within an XML complex type, a business object attribute can represent the
kinds of complex-type content shown in Table 28.
Table 28. 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 23 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 27 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 27. 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 is, 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.
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:
A business object attribute that represents an XML attribute can also include the following tags in its application-specific information:
For example, suppose an XML attribute has the following definition:
<xsd:attribute ref="Name" form="qualified"></xsd:attribute>
Its associated business object attribute would have the following format:
[Attribute] Name=Name Type=String AppSpecificInfo=attr_name=Name;type=attribute;attr_fd=qualified ...
If an XML attribute does not specify the form attribute, the value of the attributeFormDefault attribute (on the schema element) determines whether attribute names are qualified. For more information, see Qualified component names.
For example, suppose an XML attribute has the following definition:
<xsd:attribute ref="ns2:Name"></xsd:attribute>
Its associated business object attribute would have the following format:
[Attribute] Name=Name Type=String AppSpecificInfo=attr_name=Name;attr_ns=http://www.example.com/ns2; type=attribute ...
For a complete example of a schema document that includes XML attributes defined in a second namespace, see Schema namespaces.
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.
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.
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.
XML documents that refer to schema locations for their schema documents must include the following information:
This attribute associates the name of a namespace with a schema location. If the schema document uses a target namespace, the name of this target namespace must match the namespace that the xsi:schemaLocation attribute (in the XML document) specifies.
This attribute identifies a schema location. If the schema document does not use a target namespace, the XML document includes the noNamespaceSchemaLocation attribute to identify a single schema location.
For example, suppose the XML document has the namespace declaration in Figure 28.
Figure 28. 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;
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.
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.
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:
The XML ODA is capable of processing most schema documents. However, it does not support the following schema-document structures: