XPath

XPath is a syntax used for addressing certain parts of an XML document. It can also be used to test whether a node matches a pattern ( the pattern being the XPath ) – this property is used by XSLT.

It is difficult to point out strengths and weaknesses, since XPath is a relatively simple technology, designed with a very specific purpose in mind. Over the years since it was introduced, XPath has proven it’s value, and is a very important part of XML. The most common usage is in the context of XSLT, to select nodes onto which to apply formatting. It is obvious that some mechanism of selecting nodes is necessary in this context, not simply desirable; and XPath is the natural consequence of this requirement.

Assuming this well-formed XML document:

 1 <?xml version="1.0"?>

 2 <movies>

 3     <movie >

 4         <title>Hunger</title>

 5         <rating>7.6</rating>

 6         <price>15.00</price>

 7         <year>2008</year>

 8     </movie>

 9     <movie>

10         <title>Year One</title>

11         <rating>5.0</rating>

12         <price>12.00</price>

13         <year>2011</year>

14     </movie>

15     <movie>

16         <title>Pulp Fiction</title>

17         <rating>9.0</rating>

18         <price>10.00</price>

19         <year>1994</year>

20     </movie>

21     <movie>

22         <title>The Godfather</title>

23         <rating>9.2</rating>

24         <price>15.00</price>

25         <year>1972</year>

26     </movie>

27     <movie>

28         <title>Apocalypto</title>

29         <rating>7.8</rating>

30         <price>17.00</price>

31         <year>2006</year>

32     </movie>

33 </movies>

XPath can be used to select a particular element. For example, to view the titles of all the movie elements, the following XPath expression can be used:

 movies/movie/title

To view only the tiles of movies released after year 2000:

 /movies/movie[year > '2000']

To view the first two books:

/movies/movie[position() < '3']

Some of the inconveniences of XPath include the fact that it has it’s own syntax that one needs to learn; it’s a language within a language. XPath includes quite a number of functions ( http://www.w3.org/TR/xpath/#corelib ), which means that proficiency is not easy to achieve, and can become very difficult to read. Here’s an example from the XPath specification:

 /child::doc/child::chapter[position()=5]/child::section[position()=2]

It selects the second section of the fifth chapter of the doc document element.

On the other hand, the syntax is purposefully designed to be similar to the way file and folder paths are described on Unix systems, and having some familiarity with the Unix command line can ease the process of becoming comfortable with XPath. For example, the ‘.’ has a conceptually similar significance – in Unix, it signifies the current directory, while in XPath the current element. In a similar vein, ‘..’ can be used on the Unix command line as a shortcut for the parent of the current folder, while in XPath it means the parent of the current element. Hierarchy is described using the slash in both cases.

XML namespaces

Namespaces, a familiar concept to C++ and Java programmers, have a similar role in XML – to prevent name clashes. The problem of name clashes has the potential to be more acute with XML due to it’s versatility and flexibility. XML has a wider and more difficult to anticipate application domain, which makes namespaces a very important component to ensure a way of mitigating potential name conflicts.

For example, a file containing information about a module taught at a university might have the following structure:

1 <?xml version="1.0"?>

2 <module>

3     <ID>CMT3315</ID>

4     <tutor>Ray Adams</tutor>

5 </module>

And another file could contain information about a modules in a software system:

1 <?xml version="1.0"?>

2 <module>

3     <name>Graphical User Interface</name>

4     <priority>high</priority>

5 </module>

These documents could be included in the same XML document, via external entities – which would lead to two elements having the same name, but at the same time being completely unrelated. The name of XML elements is described as the element’s ‘type’ in the XML standard (http://www.w3.org/TR/REC-xml/#sec-starttags ), and all elements at the same hierarchical level are likely to be assumed as belonging to the same type.

Namespaces provide a way of differentiating between elements with the same name, but which are unrelated. The document containing both the above elements would end up looking like this:

1 <?xml version="1.0"?>

 2 <root xmlns:t="teaching" xmlns:s="software_systems">

 3     <t:module>

 4         <ID>CMT3315</ID>

 5         <tutor>Ray Adams</tutor>

 6     </t:module>

 7     <s:module>

 8         <name>Graphical User Interface</name>

 9         <priority>high</priority>

10     </s:module>

11 </root>

This is a well-formed document, and there are no ambiguities since the two different types of module elements are placed in different namespaces, therefore avoiding name conflicts.

Data modelling with XML

Needs work: Expand example ( w. code ), ID-REFS, XLink http://www.ibm.com/developerworks/xml/library/x-xdm2m.html

Logical data modeling usually occurs largely at a high level, outside the constraints of particular technologies, such as XML or SQL. However, since the resulting data model will ultimately be implemented in one ( or more ) of the available technologies, the logical data model might be adjusted for the particular computing system on which the physical data model is to be implemented – in this case, XML.

A logical data model consists of three main components: entities, attributes, and relationships (http://web.archive.org/web/20080509063521/http://www.dbmsmag.com/9506d16.html ). XML provides a robust platform for implementing entities and attributes, but relationships can be more difficult to express ( http://www.tdan.com/view-articles/5538 ).

The hierarchical structure of XML can be used to convey basic relationships, such as one-to-one and one-to-many; for example, a document called ‘Module’ can contain one or more ‘Tutor’ elements. This can be thought of as expressing either an one-to-one relationship ( if the module only has one tutor ), or as one-to-many, if the module contains multiple ‘Tutor’ elements.

Encodings in XML

The character set used throughout an XML document can be declared as part of the first line of the document, inside the xml declaration:

1 <?xml version="1.0"? encoding="UTF-8"?>

If no encoding is declared, parsers will generally try to guess which encoding is used, first by looking at the first bytes of the file. If characters outside the assumed encoding are detected, the parser will try to find an alternative encoding that will contain it. If the characters are not recognized, the parser should stop processing (http://www.w3.org/TR/REC-xml/#charencoding ).

XML encodings can be divided into three categories, the most common encodings being Unicode/ISO/IEC10646 encodings and transformations: "UTF-8", "UTF-16", "ISO-10646-UCS-2", and "ISO-10646-UCS-4". UTF-8 is the most used encoding (http://w3techs.com/technologies/overview/character_encoding/all ), accounting for 67% of websites which use a known character encoding.

The main advantage of UTF-8 is that it can encode any Unicode character, and any valid ASCII text file is also a valid UTF-8 document. This is due to the fact that UTF-8 characters do not have a fixed width ( in bytes ), but can occupy from one to six bytes; and since it was designed with backwards-compatibility with ASCII, the first 127 characters are the same for ASCII and UTF-8.

Among disadvantages, the major drawback of UTF-8 is that for certain languages, it will take up more space. Taking Romanian as an example – the word “ampulă” cannot be represented with ASCII because of the “ă” character ( http://www.fileformat.info/info/unicode/char/103/index.htm ); however, the ISO/IEC 8859-16, informally known as “Latin-10” or “South-Eastern European” encoding defines the character I need as 0xE3, so I would use this encoding for my document. ISO-8859-16 is a single-byte encoding, so it is very efficient and suited for situations when I don’t need other non-ASCII characters.

However, to represent “ă” using UTF-8, two bytes are needed: 0xC4 and 0x83, because it is decomposed into 'LATIN SMALL LETTER A' ( 0xC4 ) and 'COMBINING BREVE' ( 0x83 ), hence occupying double the amount of space. Therefore, if space were a concern, I would use the ISO-8859-16 encoding for Romanian texts.

However, it is unpractical to represent Chinese characters with any encodings which don’t support many characters. Single-byte encodings work for Romanian and other languages with a small number of characters, but not for languages which use ideograms, such as Chinese or Japanese. In this situation, UTF-8 becomes the better option.

XML Entities: possible issues

XML entities can be used to store pre-defined text fragments, which can then be used throughout the XML document. The entities are replaced with the text they represent; such entities are known as ‘General Entities’.

Another type of entities are the ‘Parameter Entities’ – which are to be used only inside the DTD. It is important to distinguish between them because they occupy different namespaces, and are recognized only in their respective context. ( http://www.w3.org/TR/REC-xml/REC-xml-20081126.xml#sec-physical-struct )

Not distinguishing between the two types of entities can be a source of errors; for example, we might have the following XML document:

1 <?xml version="1.0"?>

2 <!DOCTYPE my_doc [

3     <!ENTITY % ParEntity "This is a parameter entity" >

4     <!ENTITY GeneralEntity "This is a general entity" >

5     <!ELEMENT my_doc (#PCDATA | item )*>

6     ]>

7 <my_doc>

8     &ParEntity;

9 </my_doc>

This document is not valid, because ParEntity is a parameter entity. Because general and parameter entities are in different namespaces, we can simply declare another general entity, with the name ParEntity:

4     <!ENTITY ParEntity "This is another general entity" >

The document would then be valid. Obviously, having two entities with the same name is generally not a good idea, since it can easily lead to confusion, and is best avoided when possible.

General entities can hold data other than text, for example images or sounds. But these powerful capabilities open the door for a range of mistakes, normally of no concern to XML.

One example is the location of the resource, specified after SYSTEM or PUBLIC inside the external entity declaration; it is known as the system identifier, and is meant to be converted to a URI reference. Relative paths are normally relative to the document within which the entity is declared, but the final URI might be affected by the requirements of particular DTD’s, or might be interpreted in a non-conventional manner by applications. This can lead to the inability to correctly resolve the URI. Additionally, the incorrect NDATA might be specified, which will lead to the file being interpreted as the wrong type of file.