Trace Galloway

Subscribe to Trace Galloway: eMailAlertsEmail Alerts
Get Trace Galloway: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: XML Magazine

XML: Article

Dive into XML

Dive into XML

For this month's column I thought I'd share some of the real-world questions we've received over the past year from our "Ask the Xperts" forum on Infoteria's Web site ( These problems range from XSLT recursion, B2B implementations, DOM, SAX, JDOM, and UDDI to Web services using XML technologies. I've included some of my favorites from the thousands of questions we've received.

Q: I'm transforming XML data to HTML. When I use Infoteria's iXSLT to do transformations, it leaves the XML declaration string. Why?
By not specifying the output method using <xsl:output method="html"/>, you're telling the processor to output XML by default. In accordance with the XSLT 1.0 Recommendation, an XSLT processor is required to provide the XML declaration in the output if it's provided in the input XML source. The following is from the XSLT 1.0 Recommendation:
The default for the method attribute is chosen as follows. If

  • the root node of the result tree has an element child,
  • the expanded name of the first element child of the root node (i.e., the document element) of the result tree has local part html (in any combination of upper and lower case) and a null namespace URI,
  • and any text nodes preceding the first element child of the root node of the result tree contain only whitespace characters, then the default output method is html; otherwise, the default output method is xml. The default output method should be used if there are no xsl:output elements or if none of the xsl:output elements specifies a value for the method attribute.

    The foregoing rule also includes the absence of the <xsl:output> altogether. In the stylesheet you've written (not included in this article), if you look at the output document, you'll see that your result tree doesn't meet the requirements outlined above. To be honest, although I've read the Recommendation several times, I've always felt the authors were somewhat ambiguous in this area.

    The "and" at the beginning of the third requirement leads one to believe that either the first rule must be met or the second and third rules must be met. In reality, all three must be met for the default output method to be HTML. When transforming from XML to XML, use the <omit-xml-declaration="yes"/> attribute in your stylesheet to achieve the same result.

    Q: I'd like to convert four AS/400 DB2 databases into XML documents so I can send (DB2 AS/400 - Oracle mapping) the XML docs to an Oracle DB in another department. I'd also like to do the same in the other direction: Oracle -> AS/400 DB2. Is this possible?
    Producing XML documents from a DB2 database and then writing those documents into an Oracle database is precisely what Infoteria's iCONNECTOR products are designed to do. iCONNECTOR is a bidirectional tool that allows you to create XML from databases and write XML data into databases. The iRULEGENERATOR graphical mapping utility is included with all of the iCONNECTOR products and it provides a user-friendly environment that allows users to graphically define relationships between their XML data structures and database tables and fields. In addition, these products are designed to run on Windows NT/2000 and can be run as a Windows service on either platform. All of the iCONNECTOR products provide both a Java and COM API through which C++, Java, VB, or other client applications can access the iCONNECTOR service functionality. The products don't need to be run on the same machine as the database, and one iCONNECTOR (per database type) can access any number of databases. You mentioned that you have four DB2 databases; one iCONNECTOR for DB2 can be used to access the information stored in all of them.

    Q: We want to use XML for EDI. We have some experience in EDIfact, but a customer wants to send us XML-based data, which we need to transfer into our IBM AS/400 DB2 database. How might we receive/send XML documents and bring them into our database?
    You might use a component like Infoteria's iMESSENGER, which is designed to monitor a POP3 or iMAP4 mailbox looking for XML data as either a message attachment or as well-formed XML directly in the body field of the message. Once received, iMESSENGER extracts the XML and writes it into a working directory. From here iMESSENGER can be configured to initiate an internal process to write the information into your database. That internal process could be iCONNECTOR, a fully functional 30-day trial version, which can be downloaded from the Web site.

    Q: Is there a way to generate XML from a DTD using some type of an editor?
    Absolutely. XML Spy from Altova Corporation allows you to create a new XML document based on an existing DTD or schema. XML Spy is without a doubt the preferred XML/XSL editor when working in the XML environment. You can download a free trial version at After downloading the install program, run through the setup routine and you'll come to the components download portion of setup. When you choose to install additional components, install Infoteria's iXSLT as your default processor for XSL Transformations. Once you've set up the program, run it and choose new XML document from the file menu. You'll be prompted with a dialog box that asks if you want to use an existing schema or DTD as the basis for your new XML document.

    Q: I'm evaluating the iXSLT product and so far I'm very impressed. I have one question regarding your support for ID/IDREF: Is there any?
    Yes, with the following notes: (1) If the ID attribute has been defined in an external DTD subset, remember to use the -g or -G (iXSLT command line switches) to ensure that the processor reads in the external DTD; (2) iXSLT 2.0c supports xsl:key and it may be used when necessary - see the XSLT 1.0 REC for complete details; (3) when using ID, IDREF, and IDREFS, refer to section 12.2 of the XSLT Recommendation (and accompanying specifications) for proper usage. The XSLT 1.0 REC can be found at (a full discussion of xsl:key, ID, IDREF, and IDREFS is outside the scope of this Q&A article. I hope to cover that topic for XML-Journal in the future).

    Q: Why doesn't your iXSLT processor convert the XML closing tags from <br/> to the standard HTML <br>?
    When an XSLT processor creates the result tree as an XML document, conforming to the XSLT Recommendation's section 16.2 HTML Output Method isn't required.

    The HTML output method should not output an end tag for empty elements. For HTML 4.0, the empty elements are area, base, basefont, br, col, frame, hr, img, input, isindex, link, meta and param. For example, an element written as <br/> or <br></br> in the stylesheet should be output as <br>.

    Use the <xsl:output method="html"/> and the processor will recognize the names of HTML elements regardless of case. For example, elements named br, BR, or Br should all be recognized as the HTML br element and output without an end tag. If you include the <xsl:output method="html"/> element in your stylesheet, you'll see that the <br/> elements in your stylesheet do get converted into <br> elements in your HTML result. In addition, the XML declaration will no longer be present.

    Q: My current back-end system runs on an MS Access 2000 DB. One of my largest suppliers has requested that we implement an electronic invoicing system based on the RosettaNet framework. What do I need to do to convert my current paper system to an electronic RosettaNet-based one?
    Infoteria offers iCONNECTOR for MS Access and Asteria Server for RosettaNet. The former allows you to extract the relevant data from your Access DB and move it into the appropriate fields in a RosettaNet-compliant XML document (the "Service Content" portion of your RosettaNet message). From there it's a simple, straightforward process to map your data between the two structures.

    Once you've produced your PIP 3C3 XML document (essentially, your "electronic" invoice), you have a couple of choices. First, you could develop a process consisting of one or more applications that converts the XML document you produce from the DB into a truly compliant RosettaNet Object (RNO) or RosettaNet Business Message (RBM). This "process" would at a minimum need to include functionality to create the required additional headers (Preamble, Service Header, and possibly a Delivery Header), a mechanism to validate your XML document against the PIP 3C3 DTD, and the PIP 3C3 RosettaNet Message Guideline. It would also need to add binary length information to the resulting document, include attachments inside your resulting RNO or RBM, and potentially provide a transport mechanism to send the document to your supplier.

    The B2B server Asteria includes the functionality listed above as well as scheduling services, multiple transport protocol support, GUI-based tools to allow administrators to configure TPAs between partners, scripting facilities, and many others. It's available in a variety of configurations.

  • More Stories By Trace Galloway

    When he’s not diving for lobsters, Trace Galloway is a Sr. Sales Technologist for Infoteria Corporation (, an XML software development company based in Tokyo and Beverly, Massachusetts. He is an expert in XML and XSLT technologies and specializes in RosettaNet B2B implementations.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.