Avoiding Errors


We interrupt this description of a language to give you some practical pointers on avoiding errors.

First, if you work with the environment described in Appendix B, you'll find that the XPath expression causes an error if the syntax is incorrect but does not cause an error if names or values are not in the XML under review. (You receive no error message, for example, if you type Category instead of @Category.) That lack of errors doesn't extend to every other product that incorporates XPath, however. When you work in BPEL, you'll find that an empty set itself may cause an error if you copy an empty set to a variable.

Second, when you work with XPath in an XML file rather than through a user interface, consider the following points:

  • Delimit a string with single quotes (or the characters ') if the string is in an expression that is delimited by double quotes. Similarly, delimit a string with double quotes (or the characters ") if the string is in an expression that is delimited by single quotes. Use of the same kind of quotation marks for the string and the expression ends the expression prematurely.

  • To express comparison operators that include angle brackets, use the following characters:

    • > for greater than (>)

    • &lt; for less than (<)

    • &gt;= for greater than or equal to (>=)

    • &lt;= for less than or equal to (<=)

  • Use &amp; if you wish to type an ampersand (&).

Last, when you're working on a real-world problem, try to recall a namespace-related issue that we now describe.

If an XML element is in the default namespace, you cannot access the element node by name unless the XPath expression uses a prefix when referring to that name. In the following XML source, for example, CarPolicy is in namespace defaultNamespace.

 <other:Insured xlmns="defaultNamespace"                 xmlns:other="otherNamespace">    <CarPolicy type="Antique"/> </other:Insured> 

The next XPath expression, however, resolves to an empty set because CarPolicy is not being addressed correctly.

 /other:Insured/CarPolicy 

To access the CarPolicy node, you can use syntax (as shown later) for accessing a node without referencing a node name at all. The solution that applies more often, however, is to ensure that the XPath expression has access to and uses the appropriate namespace.

To demonstrate the solution, we need to show the XPath expression in its native habitat, inside an XML file. Assume, for example, that the XPath expression resides in the from element of a BPEL process, as shown next.

 <from xmlns:abcde="defaultNamespace"       xmlns:other="otherNamespace">    $myVariable/other:Insured/abcde:CarPolicy </from> 

The BPEL variable ($myVariable) that begins the XPath expression contains XML-based data such as a transmitted message. In this case, the specific variable contains the other:Insured node that we just described. The location path that follows the variable identifies how to access the data inside that variable.

Do you see what we've done? The XML element that contains the XPath expression has the information necessary to ensure that the XPath expression works. Specifically, the XPath expression has access to a prefix (abcde) that in turn refers to the namespace URI called defaultNamespace. The namespace problem is fully solved because CarPolicy is being addressed with a prefix that refers to defaultNamespace.




SOA for the Business Developer. Concepts, BPEL, and SCA
SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series)
ISBN: 1583470654
EAN: 2147483647
Year: 2004
Pages: 157
Authors: Ben Margolis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net