More on XLE and XML File Creation

by Kevin Vandever

In the article "Automate XML File Creation with XLE," I provided an overview of XLE technology and explained where to find it, how to download and install it, and gave some basic ways to update a document type definition with XLE information in order to create DTD with source annotation, or DTDSA. In this article, I will provide more information centered on creating the DTDSA, so you have the entire toolset necessary to dynamically generate XML from your database.

More on Binding Variables

In the last article, I briefly touched on the binding specification, or BSP. The BSP is used to bind elements together and to build the XML document. The syntax for a BSP is '::', followed by a binding parameter, ':=', and a list-valued function. BSPs must appear at least once after every repetition symbol, and they may optionally appear after any DTD constructs that are not #PCDATA, CDATA, or choice declarations. The following is an example of a BSP:

<!ELEMENT BillTo (#PCDATA :field(company, name, x)) 
:: x:= row(company, <coid>,<10>) >

The first line states that the #PCDATA is a placeholder for the value specification, or VSP (refer to last article for more on the VSP), represented by the list-value function field(company, name, x), depending on what the variable x is. The second line binds x to the #PCDATA construct by stating that x is in the company file where the coid field is equal to 10. This will give the XML document the name (as defined in the first line) of the row contained in bound variable x. In other words, the name for the company ID 10.

DTDSA scopes the binding variables dynamically. As the XML document is built from the first element, the scope of a binding variable is active for the remainder of the DTDSA, until it encounters a binding variable of the same name in an offshoot element. What that means is that binding variable x is bound to the DTD construct that it modified, as in the previous example. But it also applies to all subconstructs and annotations within that construct until x is redefined. A subconstruct is any construct using a variable from a previous construct. In the last example, if the variable name were later used in an element declaration (<!ELEMENT name), that would be considered a subconstruct. Let's look at another example.

<!ELEMENT po (id, buyer, seller,
(lineitem)*:: w:= row(lineitem, <poid>, <field(po, poid, r) >) )
:: r:=row(po, <poid>, <in0>) >

In this example, r can be applied to all the inner constructs and annotations. That means that id, buyer, seller, (lineitem)*, and w:= row(lineitem, <poid>, <field(po, poid, r) >) are all within r's reach. If an element declaration is used for seller, for example, the binding variable r can be applied in that subconstruct to determine the value for XML. Note that the in0 variable is taken from the first input parameter when the XLE command was called. The binding variable r does not apply to the element declaration po, in this case, because it is outside of its scope. Another way to look at it is that r cannot apply to the po element decaration because it is inside that declaration. However, it can apply to the rest of the constructs and annotations because it is defined outside of them, as determined by the arrangement of the parentheses. To make r apply to po, you would have to change the DTDSA to the following:

<!ELEMENT po (id, buyer, seller,
(lineitem)* :: w:= row(lineitem, <poid>, <field(po, poid, r) >) ) >
:: r:=row(po, <poid>, <in0>)

What I did was move the right angle bracket (>) for the po element declaration and placed it before the ::r:=row(po, <poid>, <in0>) value-list function, and now r applies to the whole element because it is defined outside of it. Clear as mud, right? Well, it was to me, too, in the beginning, but the more I played with it, the easier it became.

Value List Functions

Up to this point, you have seen examples using the row and field value-list functions, but XLE includes many more. What follows are several other value-list functions, along with a description of the functions:

row(Table, <Column1,...,Columnn>, <Value1,...,ValueN>) 

The row function used in this manner will retrieve the rows from the table called Table, when the condition columns equal their respective condition values.

Column1=Value1, ... , ColumnN=ValueN.row(Table)

The previous use of the row function will retrieve all rows from Table.

The unique_row function performs much like the row function, except that duplicate rows are removed. It is coded as follows:

unique_row(Table, <Column1,...,ColumnN>, <Value1,...,ValueN>) 

The projected row (pjrow) function retrieves all rows from Table, containing only values of the target columns in each row.

pjrow(Table, <TargetColumn1,...,TargetColumnK>)

This following use of the projected row retrieves the rows from Table, where the condition columns equal their respective condition values (just as the row function works), and each row will contain only values of the target columns.

pjrow(Table, <TargetColumn1,...TargetColumnK>, 
   <Column1,...,ColumnN>, <Value1,...,ValueN>) 

The unique_pjrow function examples, below, work the same as the pjrow function, except that duplicates are removed.

unique_pjrow(Table, <TargetColumn1,...,TargetColumnK>)

unique_pjrow(Table, <TargetColumn1,...TargetColumnK>, 
   <Column1,...,ColumnN>, Value1,...,ValueN>)

The field function returns the value of Column of row x, where x is a variable representing a row or projected row extracted from Table. The value of x is assigned a binding specification. It is coded as follows:

field(Table, Column, x) or equivalently, field(Table, x.Column)

Parameter Passing

Now that you have seen how to build the access.cfg file, from the previous article, and have a better understanding of how to build the DTDSA file (some practice will be necessary to really understand it), you are now ready to build an XML document. The final thing you need to understand is parameter passing. I showed you how to call XLE from the command shell. Recall that you can run XLE by entering the following from the command line:

Java XLE kevin.dtdsa 100 200 

This will run XLE using a DTDSA file called kevin.dtdsa, and pass in two parameters (in0 and in1) that are equal to 100 and 200 respectively. The values in these variables will replace their respective variable assignments inside the DTDSA file.

Putting It All Together

The information from my last article, combined with the more advanced information from this one, will more than get you on your way to automatically generating XML files from your DB2, or any other JDBC-compliant, database. Download the XLE technology from IBM alphaWorks and mess around with it. Depending on your overall understanding of XML, it may take you a while to really understand XLE, but be patient. If you transport your legacy data via XML, XLE may be the ticket to doing so more effectively.

Sponsored By WORKSRIGHT SOFTWARE

On June 30, 2002, $$$$$$$$    Postal Rates went UP!    $$$$$$$$ On July 1, 2002, $$$$$    you wanted your postage bill to go down.    $$$$$ We have the solution! CASS certify your mailing names and addresses and presort your outgoing mail and save. Our CASS certification software ensures that your address files have valid ZIP Code and address information. Our presort software ensures that you can properly prepare you mail for delivery to your Post Office. WorksRight Software, Inc. is the number-one source for iSeries and AS/400 CASS, presort, ZIP Code, and area code software and data. Visit our Web site - www.worksright.com - to learn more about our CASS and presorting software, or contact WorksRight Software, Inc., phone 601-856-8337, e-mail software@worksright.com .