- What Is a Parser?
- The Parser and the Application
- Document Object Model
- Getting Started with DOM
- Managing the State
- Common Errors and How to Solve Them
- DOM and Java
- DOM in Applications
This chapter is from the book
This chapter is from the book
This chapter is from the book
Common Errors and How to Solve Them
In this chapter, you have learned how to use XML parsers, particularly DOM parsers, from JavaScript. A discussion of parsers would not be complete without a discussion of common parsing errors and how to solve them.
This section deals with debugging XML documents when the parser reports an error.
XML Parsers Are Strict
When debugging XML documents, it is important to remember that XML parsers are strict. They complain for errors that an HTML browser would silently ignore.
This was a design goal for the development of XML. It was decided that HTML had grown too difficult to implement because the browsers were too lenient. According to some estimate, more than 50% of the code in a browser deals with correcting errors.
That's a huge burden on the browser developers and it may explain why competition in the browser space is limited.
Furthermore, XML has been designed with a wide range of computing platforms in mind. This includes regular desktop machines as well as smaller devices (smartphones, PDAs such as the PalmPilot, and so on). These devices lack the memory and power to recover from complex errors.
To minimize the risk of errors in XML documents, I suggest you adopt a validating XML editor such as XMetaL (http://www.xmetal.com) or XMLSpy (http://www.xmlspy.com). Such an editor validates your code as you write. Depending on the options, the validating editor may or may not enforce a DTD but it always enforces the XML syntax.
Error Messages
Parsers produce error messages that are often confusing. XML parsers are written with compiler technology. Consequently, error messages are similar to what you should expect from a compiler: helpful, but they rarely find the real error. Again, an XML editor may help. The best XML editors provide extra guidance about errors which makes it easier to fix them.
In the best case, the error message points to the problem. For example, given the following fragment:
<p>Send comments and suggestions to <url protocol="mailto"> bmarchal@pineapplesoft.com.</p>
The parser generates an error message similar to this (the exact message depends on your parser):
</url> expected
And it is right. The fragment misses a </url> closing tag.
Unfortunately, the error message can be very confusing. Given the following fragment:
<p>Send comments and suggestions to <url protocol="mailto> bmarchal@pineapplesoft.com.</url></p>
the parser generates two error messages:
attribute value must not contain '<' "</p>" expected
However, these error messages are incorrect. The real problem is that the attribute has no closing quotation mark. The correct message should have been
" expected.
Instead, the parser thinks that the attribute continues until the end of the line. When it reaches the end of the line, the parser is confused and it misses the p closing tag.
As you can see, it's important to take error messages with a grain of salt.
XSLT Common Errors
When writing XSLT style sheets, it is very common to forget to close HTML elements. However, in XML, a p element must have an opening and a closing tag.
The following line is guaranteed to confuse the parser:
<xsl:template match="p"> <p><xsl:apply-templates/> </xsl:template>
Fortunately, the error message ("</p>" expected) is clear.
Similarly, <br> is an empty tag. In XML, empty tags have the format <br/>. Again, the error message ("</BR>" expected) is useful to pinpoint the problem.
Another common error is to forget the attribute with for-each, value-of, or if elements. This is invalid XML coding and the parser will report an error:
<xsl:value-of="title"/>