Show description

Both aspects of the XPath context are described in Chapter 4 of this book. A Language for Processing Sequences The striking feature of the XML data model is that the information is hierarchic. The relationship from an element to its children is intrinsically a one-to-many relationship. Moreover, the relationship is inherently ordered. Sometimes you don’t care about the order, but it’s part of the nature of XML that the order of elements is deemed to be significant. This means that when you write an expression such as «author» (which is short for «child::author», and selects all the elements that are children of the context node) then, in principle, the result is a sequence of elements.

Another example of a weakly typed language is JavaScript. The conventional wisdom for database query languages is that they should be strongly typed. A strongly typed language has lots of rules about how you can use values, depending on their type. Many programming languages, such as Java, for example, are also strongly typed. Although weak typing appears to be more user-friendly, it has many disadvantages. One of the main disadvantages is that the processor isn’t able to do so much work at compile time, instead it has to make most of the decisions at runtime.

But the type system of XPath is something that is highly distinctive, so it deserves a place as one of the key characteristics that gives the language its flavor. I’ll be exploring the type system in depth in Chapter 3. Here, I’ll just give a few highlights, as a taste of things to come. ❑ We need to distinguish the types of the values that XPath can manipulate from the types that can appear as annotations on nodes. ❑ Atomic types can appear in both roles: You can declare an XPath variable of type integer, and you can also validate the content of an element or attribute as an integer, following which the element or attribute will be annotated with this type.