XML DataWindows

By Roy Kiesler	Article Rating:
January 1, 2003 12:00 AM EST	Reads:	9,453

Related
Print
Email
Feedback
Add This
Blog This

XML is fast becoming the de facto industry standard for intercomponent and interapplication data transfer. While XML is more commonly used in distributed environments, it can be just as useful, and, at times necessary, in more traditional client/server applications.

The PowerBuilder DataWindow has always excelled in the tasks of retrieving, presenting, and manipulating relational data. With the introduction of XML export and import features, the DataWindow is once again poised to handle the challenges of today's and tomorrow's technologies.

What Is XML?
The Extensible Markup Language is considered the de facto standard for the delivery of structured data on the Web. A subset of SGML, it's a markup language that's used primarily to describe data similar to the way HTML is used to describe the visual structure of Web documents.

XML Terminology
The terminology used to describe XML documents is defined in the body of the XML 1.0 specification, available from the World Wide Web Consortium (W3C) Web site at www.w3.org/TR/REC-xml. I've paraphrased a relevant subset:

XML declaration: Denotes the beginning of an XML document; specifies the version of the XML specification being used, and, optionally, the document's encoding. For example:

<?xml version="1.0"?>
<?xml version="1.0"? encoding="UTF-8">

Element: It's the basic building block of an XML document. One or more elements may be contained by an XML document, the boundaries of which are either delimited by start tags and end tags, or, for empty elements, by an empty element tag. Each element has a type, identified by name, sometimes referred to as its "generic identifier" (GI), and may have a set of attribute specifications. The text between the start tag and end tag is called the element's content. For example:

<name>content</name>
<name/>
<name attribute="value">content</name>

Comment: Similar to HTML, comments may appear anywhere in a document outside other markup; in addition, they may appear within the document type declaration at places allowed by the grammar. They're not part of the document's character data, thus an XML processor need not, but may, make it possible for an application to retrieve the comments' text. For compatibility, the string "--" (double-hyphen) must not occur within comments. For example:

Processing instruction (PI): Allows an XML document to contain directives that tell external applications how to process the document's character data. For example, the following PI directs a Web browser application to use the specified cascading stylesheet to render the content of the document at hand:

<?xml-stylesheet type="text/css" href="styles.css"?>

CDATA section: Can occur anywhere in an XML document where character data may occur; it's used to escape a block of text that contains characters that would otherwise be recognized as markup. CDATA sections begin with the string "<![CDATA[" and end with the string "]]>". For example:

<![CDATA[R & D]]>

Document type definition (DTD): Contains or points to markup declarations that provide a grammar for a class of XML documents. A DTD can point to an external subset (a special kind of external entity) that contains markup declarations; it can contain the markup declarations directly in an internal subset or consist of both subsets taken together.

Schema: A mechanism somewhat analogous to DTDs that's used for constraining an XML document structure (e.g., order, occurrence of elements, attributes). A schema provides an inventory of XML markup constructs with which to write XML documents. Schemas address some of the areas that are beyond DTD functionality, including:
- Integration with namespaces
- Integration of structural schemas with primitive data types (integers, dates, sequences, and other SQL- and Java-like data types)
- A schema definition is a valid XML document
- Inheritance for element, attribute, and data type definitions

Entity: A physical storage unit for XML data, an entity is identified by a name and has content. Each XML document has one entity called the document entity that serves as the starting point for an XML processor and may contain the whole document. An entity declaration defines an entity's name, as well as its respective data or a pointer to data that's accessible via a URL. For example:

<!ENTITY nbsp " ">
<!ENTITY % HTMLlat1
SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent">

Entity reference: An entity reference refers to the content of a named entity. For example:

%HTMLlat1;

Parsed entity: A parsed entity contains text that may represent markup or character data.

Unparsed entity: A resource whose contents may be either binary or text, and, if text, may be other than XML. Each unparsed entity has an associated notation identified by name. XML places no constraints on the contents of unparsed entities beyond the requirement that an XML processor should make the identifiers for the entity and notation available to the calling application.

Notation: Identifies by name the format of unparsed entities. A notation could refer to a specific file format for a binary entity (e.g., JPEG image, PDF document). For example:

<!NOTATION XML PUBLIC "REC-xml-1998-0210"
"http://www.w3.org/TR/1998/REC-xml-19980210">
<!NOTATION gif SYSTEM "IE">

Well formed: An XML document is said to be well formed if all of its parsed entities are properly nested, i.e., no start tag, end tag, empty element tag, element, comment, processing instruction, character reference, or entity reference begins in one entity and ends in another. For example:

<foo>well-formed</foo>
<foo>not<bar>well-formed</foo></bar>

Parser/processor: A software module that's used to read XML documents and provides access to their content and structure for a calling application.

Generator: A software module that's used to write well-formed XML documents. This module is typically a part of a single implementation that also includes a parser/processor module.

Document object model (DOM): A platform- and language-neutral interface used by an XML parser that allows programs and scripts to dynamically access and update the content, structure, and style of a given XML document. The parser loads the entire content of an XML document into a tree-like structure in memory, where the document can be further processed and the results of that processing can be incorporated back into the document. The latest DOM specification is available at www.w3.org/TR/2000/REC-DOM-Level-2-Core- 20001113/introduction.html.

Simple API for XML (SAX): An event-based parser interface that uses a request/response model to invoke handler methods registered by a calling application. Examples of parsing events include the occurrence of specific tags in a given XML document, parsing errors, etc. SAX use is best suited for parsing large XML documents, as the entire document does not need to be stored in memory. The latest SAX specification is available from www.saxproject.org.

XML validation: This is the process performed by an XML parser to verify conformance of a given XML document to the syntax defined by an associated DTD or schema.

DataWindow XML export engine: A software module that's used to produce well-formed and valid XML documents from the contents of a given DataWindow object, conforming to a specification defined in a user-specified DataWindow XML export template.

XML Parsers
The processing of every XML document begins with the parsing of the document's elements and attributes. To access the document's data, the parser must verify that the document is well formed and, optionally, validates the document's structure against a DTD or a schema referenced by the document.

XML parsers are available from a large number of software vendors, including Microsoft, Sun, Oracle, and a plethora of open-source organizations like Apache and SourceForge.Net. Implementations are available for numerous programming languages, including C++, Java, Visual Basic, C#, Perl, and, of course, PowerScript.

The following is a partial list of XML parsers.

Microsoft XML Core Services (MSXML)
MSXML is a complex hybrid product; an XML parser and an XSLT processor in one, it exports both a traditional COM interface, featuring versions for both client- and server-side (thread-safe) processing, as well as a newer .NET implementation. The MSXML parser supports all major XML standards, including DOM, SAX, namespaces, and schemas.

Apache Xerces
Xerces is an open source XML parser implemented in a variety of programming languages, including Java, C++, and Perl. The parser is fully compliant with the W3C XML 1.0 recommendation, supporting DOM levels 1.0 and 2.0, SAX 1.0 and 2.0, namespaces, and the latest W3C XML Schema recommendation.

Note: At the core of the DataWindow XML export engine is the C++ implementation or Xerces. Xerces/C++ was selected for its cross-platform foundation to ensure that the XML export functionality operates consistently on all platforms supported by the PowerBuilder Virtual Machine (Microsoft Windows, Sun Solaris, HP-UX, and IBM AIX).

PowerBuilder native xml Services (PBDOM)
PBDOM is a new set of PowerBuilder classes that enables users to create, read, write (modify), and manage DOM-based XML documents via PowerScript. PBDOM is a PBNI wrapper for the Xerces/C++ XML parser.

DataWindow Export Engine
The DataWindow Export Engine ("XML Renderer") is a new component in the DataWindow engine (see Figure 1). It uses export templates as the infrastructure for exporting row data into XML format.

The XML renderer analyzes the export template to be used for the XML output. Since the export template is an XML document, it must be parsed first. The renderer uses ,,,,, and will need the services of the XML parser/generator engine in order to analyze the template.

As the renderer analyzes the XML template, it will need to map elements from this template to actual DataWindow controls and their text values. After the mapping operation has been successfully completed, the renderer will perform the final XML syntax generation, again with the help of the XML parser/generator engine.

Export Templates
An export template defines the mapping between DataWindow elements and their XML counterparts.

The following DataWindow objects can be used in export templates:

Column
Computed column
Text control
Computed field
Nested report

The above DataWindow objects can be mapped to any of the following XML constructs:

Element
Attribute

CIO, CTO & Developer Resources

Note: Comments and processing instructions can be added anywhere in the template but can't be mapped to. CDATA sections can be added anywhere under any element, but cannot be mapped to. Nested reports can only be mapped to elements, not attributes.

Export templates are part of a DataWindow's definition. A DataWindow can contain multiple export templates. Templates are persisted in both the PBL and SRD formats of a DataWindow. A new DataWindow property, Export.XML.UseTemplate, is used to specify a named template object for use in a given export operation. This property can be set at both runtime and design time.

Note: The DataWindow.Export object currently supports XML only; however, in the future, other document types will be supported.

The syntax for XML export templates is shown in Listing 1.

Export Templates -
Graphical User Interface
The DataWindow painter in PowerBuilder 9.0 features a new view for defining and editing XML export templates. In the painter's default layout, this view is located to the left of the existing Column Specification, Data, and Control List views, and is titled "Export Template - XML".

The new XML export template view contains a TreeView control that represents the XML structure of an export template. XML entities (markup and character data) are displayed as TreeView nodes with a distinctive icon and font color to denote the type of entity. Character data is displayed as a child node of the respective element node; thus, element end tags are not shown but assumed. Markup delimiters are also implicit; i.e., angle brackets are not shown but assumed.

Only one export template can be opened in this view for editing at any given time. Figure 2 shows the new XML export template view in the DataWindow painter.

Export Template Header Section
Right-clicking anywhere on the TreeView control's background area brings up a context-sensitive popup menu that includes the following options:

New: Creates a new export template with a root and an empty detail row element.

New Default: Creates a new export template with a root and a detailed row element with a child element mapped to each column and computed field control.

Open...: Opens a previously saved export template from a dialog for editing.

Save: Saves the current export template by name. If the current template is unnamed, a dialog is displayed, prompting for a name and optional comments.

Save As...: Saves the current export template as a copy under a new name via a dialog.

Delete: Deletes the current export template. A confirmation dialog is displayed prior to this action, allowing the user to cancel the request.

Right-clicking any given node in the export template TreeView control will produce one of a number of additional context menus, depending on the node type and relative location in the tree. For example, the context menu for the XML declaration node displays the following options:

Edit...: Displays a dialog for editing the XML version, encoding, and the standalone document settings (see Figure 3).

Delete: Deletes the XML declaration. Inserting it back can be done from context menu options on the items after it.

Note: Currently, "1.0" is the only valid value for the version setting, but as the W3C XML specification evolves, additional values will also be supported. Also, deleting the XML declaration node, while allowed in a well-formed document as per the W3C specification, does not affect the generated XML - it still contains the default XML declaration.

The context menu for the document type declaration node displays the following options:

Edit...: Displays a dialog for editing the DOCTYPE name and the SYSTEM and PUBLIC identifiers.

Insert Before }: Opens a cascading menu listing all possible XML constructs allowed in this context (comment, processing instruction, and XML declaration).

Delete: Deletes the XML declaration. Inserting it back can be done from context menu options on the items after it.

Note: If the current template already has an XML declaration node defined, the corresponding option on the Insert Before cascading menu is disabled.

The context menu for the root node displays the following options:

Edit...: Puts the node label in edit mode. If the node has one or more attributes, it opens a dialog for editing the node's name and adding or editing an attribute

Edit/Add Attribute...: Opens a dialog for editing the node's name and adding or editing an attribute.

Add Child }: Opens a cascading menu listing all possible XML constructs that can be appended to the root node (element, DataWindow control reference, DataWindow expression, text, CDATA section, comment, and processing instruction).

Insert Before }: Opens a cascading menu listing all possible XML constructs that can be inserted before the root node (comment, processing instruction, XML declaration, and document type).

Note: The XML declaration and document type options on the Insert Before cascading menu will be disabled if the corresponding nodes are already present in the current template. The root node is required and can't be deleted.

Export Template Detail Section
The Detail section is graphically delineated by a gray line across the TreeView control, separating the header section from the detail section, similar to the way a detail band functions in the DataWindow painter's design view. The separator line can be repositioned by the user by checking the "Starts Detail" option on the context menu of the respective element node. This element is then referred to as the Detail Start element.

Only one element can be marked as the Detail Start element, and the root node can't be. By default, the first child of the root element is designated as this element; however, any subsequent child node (and children thereof) may be marked as the Detail Start element, effectively moving all preceding nodes to the header section of the template. At export time, only the Detail Start element, its sibling, and children will be iteratively generated for each row.

The context menu for element nodes in the detail section displays the following options, in addition to the ones displayed by the root node's context menu:

Starts detail: Positions the gray separator bar above the current node

Delete: Deletes the element node

Mapping DataWindow Elements to XML Nodes
Once the structure of your target XML document is finalized, you need to bind data values to XML elements and attributes. The mapping process is done by selecting a DataWindow column, computed field, expression, and/or text controls from a dialog. Alternatively, the user may drag and drop items from the control list painter view. The selected item appears as a child node under the respective element node in the TreeView control. Figure 4 shows the control reference dialog.

Note: Data values mapped to XML elements are treated as character data, regardless of the actual data type (number, date, etc.) of the respective DataWindow column.

Exporting XML
You can export the data in a DataWindow or DataStore object to XML utilizing techniques that are similar to those used for exporting to other formats such as PSR or HTML:

1. Using the Save Rows As menu item in the DataWindow painter when the Preview view is open

2. Using the SaveAs() method:

dw_1.SaveAs( "c:\foo\bar.xml", XML!, TRUE )

3. Using PowerScript dot notation:

ls_xml = dw_1.object.datawindow.data.xml

4. Using PowerScript Describe notation:

ls_xml = dw_1.Describe( "datawindow.data.xml" )

New DataWindow properties are used to fine-tune the generation of XML from DataWindow data. These properties can be set at runtime and design time. The following is a list of those properties and their descriptions.

Export.XML.UseTemplate is used to specify a named template object for use in a given export operation. This property can be selected at design time via a dropdown list box containing all saved export templates, or at runtime using the following syntax:

1. Using PowerScript dot notation:

dw_1.Object.DataWindow.Export.XML.UseTemplate = "value"

2. Using PowerScript Modify notation:

dw_1.Modify( "DataWindow.Export.XML.UseTemplate {= 'value'}" )

Export.XML.MetaDataType is used to specify what metadata will be attached to the XML generated by the DataWindow. This property can be selected at design time via a dropdown list box that contains all saved export templates, or at runtime using the following syntax:

1. Using PowerScript dot notation:

dw_1.Object.DataWindow.Export.XML.MetaDataType = "value"

2. Using PowerScript Modify notation:

dw_1.Modify( "DataWindow.Export.XML.MetaDataType{= 'value'}" )

Table 1 lists the possible values for this property.

Export.XML.SaveMetaData is used to specify how the generated metadata will be stored. This property can be selected at design time via a dropdown list box containing all saved export templates, or at runtime using the following syntax:

1. Using PowerScript dot notation:

dw_1.Object.DataWindow.Export.XML.SaveMetaData = "value"

2. Using PowerScript Modify notation:

dw_1.Modify( "DataWindow.Export.XML.SaveMetaData{= 'value'}" )

Table 2 lists the possible values for this property. Figure 5 shows the DataWindow painter user interface for setting the XML properties of a DataWindow.

Note: The Modify syntax can use both the numeric and enumerated values in the expression.

Importing XML
XML import templates take advantage of the export template foundation. They allow the mapping of XML elements and attributes to the corresponding relational database columns.

Unlike the export process that uses a DOM parser to construct the XML document, XML import uses a SAX parser, which offers a significant performance improvement.

Uses for the XML DataWindow
PowerBuilder developers and InfoMaker users can use the XML export features of the DataWindow in the following ways.

Client/Server Applications
PowerBuilder applications using DataWindows for data entry and/or data reporting could be enhanced with events to export select data values, or the entire contents of the DataWindow, to variously structured XML documents for use by other applications, processes, or systems within or outside the enterprise.

InfoMaker users could also export select subsets, or the entire set of data values from their report ( e.g., a Purchase Order) from within an XML tool that's designed to comply with the DTD or XML Schema of a vendor's PO, for example.

Distributed Applications
PowerBuilder NVO components using DataStores for server-side database processing or for middle-tier data management of client-side DataWindows could include a method to export the contents of the DataStore in XML. This XML could be pushed for processing by a different enterprise component or subsystem, for example, a J2EE Enterprise JavaBean or a Web service over the Internet.

Web applications using the Web Targets and/or the Web DataWindow component (HTMLGenerator90) could also include a similar export XML method on the DataStore invoked via a user action (e.g., on a shopping cart checkout) for subsequent XML processing.

Related
Print
Email
Feedback
Add This
Blog This

More Stories By Roy Kiesler

SYS-CON Media

SYS-CON Events

Navigate

International Sites

Magazines