XLink and XPointer | Beginning XML Databases (Wrox Beginning Guides)

XML varies in the meaning it applies to the results of output, such as transformation through XSL, or something like reading from a database using XQuery. One of the primary reasons for the enormous success of the Internet is the ability for web pages to link to one another all over the Internet. So, XML must provide that linking ability as well. This is because XML documents provide not only data, but also metadata, which adds meaning to data. Thus, links created using XML document data are likely to be flexible, if perhaps less predictable. Predictability is not a requirement. XLink and XPointer are XML standards established by the World Wide Web Consortium, intended to standardize the way in which hyperlinks between Internet pages are linked.

Web page hyperlinks (linking) are created and managed in XML using two parts : XLink (XML Linking Language) and XPointer (XML Pointing Language). XLink defines the standard by which web page hyperlinks are created. Those XLink hyperlink standards are thus universally understandable. XPointer refines XLink, allowing for pointing of hyperlinks to XML fragments within larger XML documents.

So, why is this stuff included in this book on XML and databases? The answer is simple. XML data can be stored in various databases, in various ways. Additionally, an XML document (or collection thereof), can exist as a native XML database in itself. Therefore, the building of HTML <A HREF . . . > (hyperlinks) in web pages, which are built from XML data, is dependent on XML content. Ultimately, those hyperlinks are very much dependent on the content of XML document data and metadata content.

What Is XLink?

In short, XLink lets you define links in a web page whose source is XML data, of one form or another. Essentially XLink enforces, or perhaps provides, a standard by which links can be generated from XML data. HTML uses the <A HREF ...> ... </A> tags to create links, linking from one web page to another. XLink allows creation of links similar to that of HTML pages. However, XLink is much more capable in that any XML document element can be created as a hyperlink. Additionally, XLink allows creation of links, which join multiple resources together, as opposed to just one page linking to another page for HTML.

The result is that any XML element in an XML document can be a link to another web page on the Internet. HTML is restricted to specific elements including <A> and <IMG> tags. Creating links in HTML documents requires that links be preconstructed as the HTML page is created (manually or automatically). XLinks are generated based on the content of an XML document, and require no human or programming intervention.

The problem with XML is that it cant provide links by itself and must rely on HTML to implement <A> tags for creating links. XLinks resolves this issue.

Simple XLinks

Why are XML links different from HTML links? HTML links are created using the <A> tag. XML elements are flexible and the tag name can be anything. So, an XML link tag name can be anything. As a result, a browser cannot decide on what is and is not a link in XML, as it can when parsing an <A> tag element in an HTML page. The obvious solution is to indicate somehow which elements in an XML document will become links.

The following example shows the syntax for creating hyperlinks (XLinks) in XML documents:

   <?xml version="1.0"?> <websites xmlns:xlink="http://www.w3.org/TR/xlink/">    <website xlink:type="simple" xlink:href="http://www.yahoo.com">Yahoo</website>    <website xlink:type="simple" xlink:href="http://www.google.com">Google</website>    <website xlink:type="simple" xlink:href="http://www.ebay.com">EBay</website>    <website xlink:type="simple" xlink:href="http://www.etrade.com">ETrade</website> </websites>

Figure 12-1 shows what the preceding sample XML script looks like in a browser. Currently, this is just XML code. I am not as of yet actually doing anything useful just demonstrating syntax.

Figure 12-1: Simple XLinks in a browser

In Figure 12-1, attributes of the website element define that these elements are part of the XLink namespace (xlink), that the XLink is a simple type of XLink, and that the XLink linked URL is defined by the href attribute value.

Basic XLink attribute syntax allows for a number of attributes for an XLink value, as shown in Figure 12-2.

Figure 12-2: The basics of XLink attributes

Figure 12-3 shows the previous example from Figure 12-1, including some new attribute settings.

Figure 12-3: Adding more XLink attributes

You can now add an XSL script such as this one:

   <HTML xmlns:xsl="http://www.w3.org/TR/WD-xsl"><BODY> <TABLE CELLPADDING="5" CELLSPACING="1" BORDER="1"> <TH BGCOLOR="silver">Website</TH> <xsl:for-each select="websites/website">    <TR>       <TD><xsl:value-of select="."/></TD>    </TR> </xsl:for-each> </TABLE></BODY></HTML>

Next , you can add in the XSL script reference into the XML file:

   <?xml version="1.0"?>  <?xml:stylesheet type="text/xsl" href="fig1204.xsl" ?>  <websites xmlns:xlink=" http://www.w3.org/TR/xlink/">    <website xlink:type="simple" xlink:href="http://www.yahoo.com" xlink:show="new" xlink:actuate="onRequest">Yahoo</website>    <website xlink:type="simple" xlink:href="http://www.google.com" xlink:show="new" xlink:actuate="onRequest">Google</website>    <website xlink:type="simple" xlink:href="http://www.ebay.com" xlink:show="new" x link:actuate="onRequest">EBay</website>    <website xlink:type="simple" xlink:href="http://www.etrade.com" xlink:show="new" xlink:actuate="onRequest">ETrade</website> </websites>

The result looks as shown in Figure 12-4, and if my browser were XLink enabled, it would contain links to the websites, not just the text names of those websites.

Figure 12-4: Adding links with XLink

You can make the example shown in Figure 12-4 function properly in Internet Explorer by substituting the xlink:actuate attribute with an onClick event by using an XML link element, and by setting link display attributes using a cascading style sheet (CSS).

XLink is not yet in production (recommended standard only) and does not actually work for my version of Internet Explorer (version 6). It is unlikely to work in version 7 either. XLink has not been imple mented in industry to a point where it is an accepted industry standard . The onClick event is neither XML nor XLink; it is Dynamic HTML (DHTML). DHTML is a combination of HTML, JavaScript, and perhaps CSS. CSS is to HTML what XSL is to XML.

The following example demonstrates the preceding information:

   <?xml version="1.0"?> <?xml-stylesheet type="text/css" href="fig1205.css"?> <websites>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="simple" xlink:sho w="new" xlink:href="http://www.yahoo.com" onClick="location.href='http://www.yahoo. com'">Yahoo</link>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="simple" xlink:sho w="new" xlink:href="http://www.google.com" onClick="location.href='http://www.googl e.com'">Google</link>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="simple" xlink:sho w="new" xlink:href="http://www.ebay.com" onClick="location.href='http://www.ebay.co m'">EBay</link>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="simple" xlink:sho w="new" xlink:href="http://www.etrade.com" onClick="location.href='http://www.etrad e.com'">ETrade</link> </websites>

The CSS script looks like this when the link tag is defined as having the color blue, the link is underlined , and the mouse cursor changes to a hand when rolling over the link:

   link { color: #0000FF; text-decoration: underline; cursor: hand }

The result of executing the preceding code is shown in Figure 12-5, which demonstrates the functioning XLink links.

Figure 12-5: Getting XLink links to function in Internet Explorer 6

Some More Advanced XLink Attributes

More detailed XLink attribute syntax is shown in Figure 12-6, which is in addition to that shown in Figure 12-2.

Figure 12-6: More advanced XLink attribute details

There are of course even more attributes. Many of the other attributes, not shown in Figures 12-2 and 12-6, are applicable to specific types of XLink ( xlink:type ). This is why additional attributes have not as yet been displayed. Lets briefly summarize different XLink types once again:

simple: Quite literally a simple link from one resource to another.
extended: A more complex link where multiple links can be joined together based on a number of other attributes.
locator: The exact location of a remote resource.
arc: Rules that define how, or the path by which links are traversed.
resource: A link to a specific resource link.

This leads us to various other XLink attributes, based on the meanings of the preceding noted XLink types, where the different attributes are applicable to different XLink types:

from and to: The xlink:from and xlink:to attributes are specific to an arc XLink type because an arc defines a link between two resources.
arcrole: This describes the role of a link in an arc between two links.
label: An xlink:title gives an easily readable form to a resource. An xlink:label gives an easily readable form to a link (the underlined text things you see in the diagram in Figure 12-5).
role: As opposed to xlink:title , which describes a resource in easily readable form, an xlink:role describes a resource in a form readable by a computer, not a person.

In the example shown in Figure 12-7, the xlink:role and xlink:title attributes are used to describe the remote resource that is linked to by the XLink.

Figure 12-7: More advanced XLink attribute details

Extended XLinks

The only XLink hyperlinks examined so far have been simple links. Extended links are also available but not widely supported. An extended XLink allows definition of multiple resources (targets of links) and many paths between all of those resources, plus paths between resources that can go in both directions.

Unlike simple XLink types, extended XLink types establish multiple connections between multiple resources, similar to the way that multiple inheritance can be constructed in an object application of an object database. Thus, extended XLinks can have child types, including locator, arc, resource, and title types. Locators are remote resources (website URLs). An arc has two child elements of xlink:from and xlink:to , defining the source and target resources of the arc link.

Extended XLink types essentially allow the linking of multiple XML documents with each other and others. The easiest way to demonstrate this is by example. Figure 12-8 shows a logical split for the demographics database (see Appendix B). Also in Appendix B is a reference to a URL on my website, which contains code for building an XML document equivalent to the relational database, entity relationship diagram (ERD), shown in Figure 12-8. What I have done in Figure 12-8 is to show a logical split in the demographics data by placing regional data on the right and more personal data on the left of the diagram. Thus, the personal information becomes language and occupation groupings, and regional data is represented by regions , countries , states, and cities.

Figure 12-8: Splitting a database by metadata structure is logically visible.

What is the purpose of splitting the metadata, as shown in Figure 12-8? The idea is to create two separate demographics databases this would create two separate XML documents and then link those two documents together using XLink. However, I am not actually going to split data logically because it is extra effort, it messes up that nicely organized relational data structure, and there is an easier way. Figure 12-8 does demonstrate that something like this can be done.

An easier way to split demographic data is to split the data rather than the metadata. The easiest solution to splitting data is to split the entity at the highest level of the hierarchy. This assumes it does not have a huge number of records. This is unlikely in any sensibly designed relational database as that entity will likely be small and static in nature. In the case of the demographics database, the simplest split is separating all the data into regions, of which there are few. At a later stage, you can link the data across different regions using data items that are common to different regions, such as years , as demonstrated in the XML documents displayed in Figure 12-9.

Figure 12-9: Splitting a database by data is physically visible.

So in Figure 12-9, I split demographics data based on regions, given that years are common to child elements of different regions. Then, you can form links between multiple regional XML documents for regions containing data based on common years. Those years are, in actuality, population figures for various countries, for various different years. Not all countries have data for all years, and some countries not even for any year at all. Additionally, all regions contain the same XML element structure in general so they all have common elements such as <country> , <city> , <languages> , or <occupations> for example. As shown in Figure 12-10, the parts of the XML document very clearly show that the year attribute of the <year> element, plus language and occupation names, are both common as data elements. Other factors such as country and city <name> elements could be construed as being linkable items but are unlikely to be useful.

Figure 12-10: Demographics data shows multiple links for both data and metadata.

So, when creating the demographics XML database in previous chapters (see Appendix B), I also created some separate documents for each region. An example region is shown in Figure 12-11.

Figure 12-11: Demographics data is split into separate XML documents for each region.

The result of splitting regions from a single demographics XML document into one XML document for each region is a collection of regional XML documents. You can use this collection of multiple region XML documents to create sensible XLink connections across that collection.

Before creating XLink code, I query one of the relational databases, from which the XML demographics documents were created in the first place. I want to isolate some data that has year, language, and occupation values that are common to more than one region. The first step is to join all the tables in the database, with all the information I need:

   select distinct year, region, country from (select r.region, c.country, p.year, l.language, o.occupation from region r join country c on(c.region_id=r.region_id)    join population p on(p.country_id=c.country_id)       join populationbylanguage pl on(pl.population_id=p.population_id)          join populationbyoccupation po on(po.population_id=p.population_id)             join language l on(l.language_id=pl.language_id)                join occupation o on(o.occupation_id=po.occupation_id) order by r.region, c.country, p.year, l.language, o.occupation) order by 1,2,3;

The result is an intersection of all the data, where everything exists, which is exactly what I am looking for. In the preceding query I am trying to find regions with common years, where each year contains both language and occupation data. This is the result:

   YEAR REGION           COUNTRY ---------- ---------------- ----------------       1965 Europe           Bulgaria       1970 Europe           Finland       1974 Near East        Bangladesh       1976 Australasia      Australia  1980 Africa           South Africa   1980 Africa           Zambia   1980 Central America  Panama   1980 Europe           Hungary   1980 Far East         Malaysia  1981 Far East         Nepal       1981 North America    Canada       1985 Europe           Finland       1986 North America    Canada       1988 South America    Bolivia       1990 Far East         Singapore

The obvious conclusion from the preceding result is that 1980 has extensive data in all requirements for multiple regions. Now I am going to refine the query to find the regions, years, languages, and occupations:

   select distinct region, year, language, occupation from (select r.region, c.country, p.year, l.language, o.occupation from region r join country c on(c.region_id=r.region_id)    join population p on(p.country_id=c.country_id)       join populationbylanguage pl on(pl.population_id=p.population_id)          join populationbyoccupation po on(po.population_id=p.population_id)             join language l on(l.language_id=pl.language_id)                join occupation o on(o.occupation_id=po.occupation_id) where r.region in('Africa','Central America','Far East') and l.language in('English','French','Spanish','Espanol') order by r.region, c.country, p.year, l.language, o.occupation) order by 1,2,3;

This is the result of the preceding query, with records containing common values in one common group highlighted (1980, English, Agriculture):

   REGION                 YEAR LANGUAGE         OCCUPATION ---------------- ---------- ---------------- ----------------  Africa                 1980 English          Agriculture  Africa                 1980 English          Clerical Africa                 1980 English          Labor Africa                 1980 English          Management Africa                 1980 English          Professional Africa                 1980 English          Sales Africa                 1980 English          Service Africa                 1980 English          Unknown Africa                 1980 French           Agriculture Africa                 1980 French           Clerical Africa                 1980 French           Labor Africa                 1980 French           Management Africa                 1980 French           Professional Africa                 1980 French           Sales Africa                 1980 French           Service Africa                 1980 French           Unknown Central America        1980 Espanol          Agriculture Central America        1980 Espanol          Clerical Central America        1980 Espanol          Labor Central America        1980 Espanol          Management Central America        1980 Espanol          Professional Central America        1980 Espanol          Sales Central America        1980 Espanol          Service Central America        1980 Espanol          Unknown  Far East               1980 English          Agriculture  Far East               1980 English          Clerical Far East               1980 English          Labor Far East               1980 English          Management Far East               1980 English          Professional Far East               1980 English          Sales Far East               1980 English          Service Far East               1980 English          Unknown Far East               1990 English          Agriculture Far East               1990 English          Clerical Far East               1990 English          Labor Far East               1990 English          Management Far East               1990 English          Professional Far East               1990 English          Sales Far East               1990 English          Unknown

One interesting point about the preceding query is that I am searching for the Spanish language as being either Spanish or Espanol. Obviously, demographics data is reliable but often sparse, haphazard, and variant. However, this is another factor that can be used to demonstrate how well generic URL linking can function with XLink, which you will examine shortly. Ultimately, it makes sense to link the preceding language data with the region of Europe, which is of course the original source of the English, French, and Spanish (or Espanol) languages.

So, now lets try to link some of the regions together using XLink, based on common data values between the different regions. Those common data values are quite clearly the years, languages, and occupations. Lets use just Africa and Europe as an example in this case. Because both are regional XML fragments, both begin as regions:

   <?xml version="1.0"?> <regions>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="extended">       <region xlink:type="locator" xlink:label="region" xlink:href="Africa.xml"/>       <region xlink:type="locator" xlink:label="region" xlink:href="Europe.xml"/>    </link> </regions>

The result of the preceding script is shown in Figure 12-12.

Figure 12-12: Basic XML interpretation of XLink

Now I can define both regions as containers for regions, years, languages, and occupations:

   <?xml version="1.0"?> <regions>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="extended">       <region xlink:type="locator" xlink:label="africa" xlink:href="Africa.xml"/>       <region xlink:type="locator" xlink:label="europe" xlink:href="Europe.xml"/>  <year xlink:type="locator" xlink:label="1980" xlink:href="Africa.xml"/>   <year xlink:type="locator" xlink:label="1980" xlink:href="Europe.xml"/>   <language xlink:type="locator" xlink:label="english"   xlink:href="Africa.xml"/>   <language xlink:type="locator" xlink:label="english"   xlink:href="Europe.xml"/>   <occupation xlink:type="locator" xlink:label="agriculture"   xlink:href="Europe.xml"/>   <occupation xlink:type="locator" xlink:label="agriculture"   xlink:href="Europe.xml"/>  </link> </regions>

The result of the preceding script is shown in Figure 12-13.

Figure 12-13: Adding labels within labels using XLink

Now I need to refine the preceding script, adding arcs to connect common data elements between the two different XML documents. You do this using arcs:

   <?xml version="1.0"?> <regions>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="extended">       <region xlink:type="locator" xlink:role="africa" xlink:href="Africa.xml"/>       <region xlink:type="locator" xlink:role="europe" xlink:href="Europe.xml"/>       <year xlink:type="locator" xlink:label="1980" xlink:href="Africa.xml"/>       <year xlink:type="locator" xlink:label="1980" xlink:href="Europe.xml"/>       <language xlink:type="locator" xlink:label="english"          xlink:href="Africa.xml"/>       <language xlink:type="locator" xlink:label="english"          xlink:href="Europe.xml"/>       <occupation xlink:type="locator" xlink:label="agriculture"          xlink:href="Europe.xml"/>       <occupation xlink:type="locator" xlink:label="agriculture"          xlink:href="Europe.xml"/>  <bind xlink:type="arc" xlink:from="africa" xlink:to="1980"/>   <bind xlink:type="arc" xlink:from="europe" xlink:to="1980"/>   <bind xlink:type="arc" xlink:from="africa" xlink:to="english"/>   <bind xlink:type="arc" xlink:from="europe" xlink:to="english"/>   <bind xlink:type="arc" xlink:from="africa" xlink:to="agriculture"/>   <bind xlink:type="arc" xlink:from="europe" xlink:to="agriculture"/>  </link> </regions>

The result of the preceding script is shown in Figure 12-14.

Figure 12-14: Connect data elements in XLink using arcs.

What I have done in the preceding script is change the <region> element XLinks to roles and added arcs connecting all defined regions to the year of 1980, the English language, and the occupation of Agriculture. This seems a little convoluted but what has actually been done is that the two regional XML documents (Africa.xml and Europe.xml) have been connected based on years, languages, and occupations. Yes, this implementation will cause conflict because the same labels are used for different things. A solution is to create three separate XLink XML documents, as opposed to splitting up the data into its nice and neat little boxes. In other words, dont fix the data to suit XLink; change XLink definitions to suit the data. Otherwise, why link both with XLink. So, each region needs to link to years, occupations, and languages, both within itself and to all other regions. However, there is no reason to place the years, occupations, and languages within the same definition. This script defines years:

   <?xml version="1.0"?> <regions>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="extended">       <region xlink:type="locator"  xlink:role="africa"  xlink:href="Africa.xml"/>       <region xlink:type="locator"  xlink:role="europe"  xlink:href="Europe.xml"/>       <year xlink:type="locator"  xlink:label="africa1980"  xlink:href="Africa.xml"/>       <year xlink:type="locator"  xlink:label="europe1980"  xlink:href="Europe.xml"/>       <bind xlink:type="arc"  xlink:from="africa" xlink:to="africa1980"  />       <bind xlink:type="arc"  xlink:from="africa" xlink:to="europe1980"  />       <bind xlink:type="arc"  xlink:from="europe" xlink:to="africa1980"  />       <bind xlink:type="arc"  xlink:from="europe" xlink:to="europe1980"  />    </link> </regions>

The result of the preceding script is shown in Figure 12-15.

Figure 12-15: XLink can refine links between multiple XML documents.

This script defines languages:

   <?xml version="1.0"?> <regions>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="extended">       <region xlink:type="locator"  xlink:role="africa"  xlink:href="Africa.xml"/>       <region xlink:type="locator"  xlink:role="europe"  xlink:href="Europe.xml"/>       <language xlink:type="locator"  xlink:label="africaenglish"  xlink:href="Africa.xml"/>       <language xlink:type="locator"  xlink:label="europeenglish"  xlink:href="Europe.xml"/>       <bind xlink:type="arc"  xlink:from="africa" xlink:to="africaenglish"  />       <bind xlink:type="arc"  xlink:from="africa" xlink:to="africaenglish"  />       <bind xlink:type="arc"  xlink:from="europe" xlink:to="europeenglish"  />       <bind xlink:type="arc"  xlink:from="europe" xlink:to="europeenglish"  />    </link> </regions>

The result of the preceding script is shown in Figure 12-16.

Figure 12-16: Further refinement of XLinks between multiple XML documents

This script defines occupations:

   <?xml version="1.0"?> <regions>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="extended">       <region xlink:type="locator"  xlink:role="africa"  xlink:href="Africa.xml"/>       <region xlink:type="locator"  xlink:role="europe"  xlink:href="Europe.xml"/>       <language xlink:type="locator"  xlink:label="africaagriculture"  xlink:href="Africa.xml"/>      <language xlink:type="locator"  xlink:label="europeagriculture"  xlink:href="Europe.xml"/>       <bind xlink:type="arc"  xlink:from="africa" xlink:to="africaagriculture"  />       <bind xlink:type="arc"  xlink:from="africa" xlink:to="africaagriculture"  />       <bind xlink:type="arc"  xlink:from="europe" xlink:to="europeagriculture"  />       <bind xlink:type="arc"  xlink:from="europe" xlink:to="europeagriculture"  />    </link> </regions>

The result of the preceding script is shown in Figure 12-17.

Figure 12-17: And yet further refinement of XLinks between multiple XML documents

Now imagine the following scenario. You use all the possible regions, years, languages, and occupations from the entire demographics set of data (see Appendix B). The result is a lot of complexity and a lot of XLinking . Too much perhaps. The real question could be something different. How much complexity can be introduced using something like XLink? And still you need to retain the desired flexibility. There may be better methods of resolving generic linking between XML data, which may of course be why XLink does not have a reputation for being widely implemented. Application level coding can also resolve these types of issues. So, perhaps much like Native XML databases and their practicality in relation to well-established and industry- tested relational databases (with XMLType data types added in), too much of a good thing (XML and XLink) may not always be quite as good a thing as you might think.

What Is XPointer?

For the demographics XML document (database), it might be best to leave the data all in a single document. Then you can link across that document, connecting things such as common valued years, languages, and occupations, using XPointer definitions. XPointer allows connecting of XLink definitions between different points within the same XML document. It is still probable that the result could be unwanted and unmanageable complexity. Additionally, the simplification of data into a single demographics XML document might introduce excessive cross linking both between and within different regions.

So, what is XPointer and what does it do? Lets begin this explanation by using simple HTML. Examine the HTML script that follows . Note how the <A NAME> and <A HREF> tags are highlighted:

   <HTML> <HEAD><TITLE>Links Within a Page in HTML - An Alphabetical Index</TITLE></HEAD> <BODY>  <A NAME="top"><B><FONT size="3" COLOR="red">Index</FONT></B></A>   <A HREF="#A">A</A> <A HREF="#B">B</A> <A HREF="#C">C</A>   <A HREF="#D">D</A> <A HREF="#E">E</A> <A HREF="#F">F</A>   <A HREF="#G">G</A> <A HREF="#H">H</A> <A HREF="#I">I</A>   <A HREF="#J">J</A> <A HREF="#K">K</A> <A HREF="#L">L</A>   <A HREF="#M">M</A> <A HREF="#N">N</A> <A HREF="#O">O</A>   <A HREF="#P">P</A> <A HREF="#Q">Q</A> <A HREF="#R">R</A>   <A HREF="#S">S</A> <A HREF="#T">T</A> <A HREF="#U">U</A>   <A HREF="#V">V</A> <A HREF="#W">W</A> <A HREF="#X">X</A>   <A HREF="#Y">Y</A> <A HREF="#Z">Z</A><HR>   <A NAME="A"><B><FONT size="3" COLOR="red">A</FONT></B></A>  <UL>  <LI>Aardvaark  <LI>Able </UL>  <A HREF="#top">Index</A><HR>   <A NAME="B"><B><FONT size="3" COLOR="red">B</FONT></B></A>  <UL>  <LI>Beer  <LI>Beer Belly  <LI>Bat  <LI>Ball </UL>  <A HREF="#top">Index</A><HR>  ... </BODY></HTML>

As shown in Figure 12-18, <A HREF> defines a link and <A NAME> defines a link target within the same document.

Figure 12-18: Demographics is split into separate regional XML documents for each region.

The objective of using XPointer is to prove the same function as shown in Figure 12-18, allowing pointing within a document. However, XPointer goes a little further, allowing pointing to a point within the same document or another document. In other words, XLink provides a link to the same, or another, XML document. XPointer enhances (or extends) the functionality of XLink by allowing a link to a specific point within the same or another XML document.

So, you can use XPointer to link to an XML fragment (part of an XML document). Lets use our various regional XML documents both source and target documents. As with HTML, you use the # (or hash) character in order to define an XPointer source and target within an XML document. The difference between HTML and XML/XLink/XPointer, when pointing into documents using XML, is that the points are flexible. In HTML, the points are not flexible. This flexibility is based on the fact that XML is not only flexible in itself, but also that the XML document is a database as well. A database is a database because its content (its data) is flexible.

This is a previous example that uses XLink to join multiple regional documents to one another:

   <?xml version="1.0"?> <regions>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="extended">       <region xlink:type="locator" xlink:role="africa" xlink:href="Africa.xml"/>       <region xlink:type="locator" xlink:role="europe" xlink:href="Europe.xml"/>       <year xlink:type="locator" xlink:label="1980" xlink:href="Africa.xml"/>       <year xlink:type="locator" xlink:label="1980" xlink:href="Europe.xml"/>       <language xlink:type="locator" xlink:label="english"          xlink:href="Africa.xml"/>       <language xlink:type="locator" xlink:label="english"          xlink:href="Europe.xml"/>       <occupation xlink:type="locator" xlink:label="agriculture"          xlink:href="Europe.xml"/>       <occupation xlink:type="locator" xlink:label="agriculture"          xlink:href="Europe.xml"/>       <bind xlink:type="arc" xlink:from="africa" xlink:to="1980"/>       <bind xlink:type="arc" xlink:from="europe" xlink:to="1980"/>       <bind xlink:type="arc" xlink:from="africa" xlink:to="english"/>       <bind xlink:type="arc" xlink:from="europe" xlink:to="english"/>       <bind xlink:type="arc" xlink:from="africa" xlink:to="agriculture"/>       <bind xlink:type="arc" xlink:from="europe" xlink:to="agriculture"/>    </link> </regions>

What you really want to do is to allow the various regions to be connected by their years, languages, and occupations. For example, the current XLink connections, shown in the preceding script, link the document of Africa.xml directly to the entire document of Europe.xml. What you want to do is to link the year of 1980 (in Africa.xml) to the year of 1980 (in Europe.xml). You need to point from fragment to fragment. Why? Its much more efficient.

So, how do you point to XML fragments? Consider the SQL query output earlier in this chapter, showing various countries with data in the year of 1980:

    1980 Africa           South Africa   1980 Africa           Zambia   1980 Central America  Panama   1980 Europe           Hungary   1980 Far East         Malaysia

You know already from previous SQL query executions that the preceding countries have common languages and occupations in the year of 1980. You also know that the different countries are stored in different regional XML documents covering Africa, Central America, Europe, and the Far East. You create XPointer fragment links with the following syntax:

   #xpointer(id("<value>"))

So, if I change the preceding syntax to this:

   #xpointer(id("35"))

or this:

   #xpointer(code("SF"))

you will find the country of South Africa, as shown in Figure 12-19.

Figure 12-19: A snapshot of different parts of the Africa.xml document

An XLink link can be built as follows:

   xlink:href="Europe.xml#xpointer(id('35'))"

So, you can alter the previous example as follows:

   <?xml version="1.0"?> <regions>    <link xmlns:xlink = "http://www.w3.org/TR/xlink/" xlink:type="extended">       <year xlink:type="simple"  xlink:href="Africa.xml#xpointer(year('1980'))"  />       <year xlink:type="simple" xlink:href="Europe.xml#xpointer(year('1980'))"/>       <language xlink:type="simple"  xlink:href="Africa.xml#xpointer(name('English'))"  />       <language xlink:type="simple"          xlink:href="Europe.xml#xpointer(name('English'))"/>       <occupation xlink:type="simple"  xlink:href="Africa.xml#xpointer(name('Agriculture'))"  />       <occupation xlink:type="simple"          xlink:href="Europe.xml#xpointer(name('Agriculture'))"/>    </link> </regions>

The result of the preceding script is shown in Figure 12-20.

Figure 12-20: Using XPointer in Internet Explorer

As a side issue, there is a benefit to using an attribute called id in that XPointer doesnt need the syntax to be specific about the code id or even the term xpointer :

   xlink:href="Europe.xml#35"

The only problem I find with the preceding example is that of conflicting instructions and methods of resolving these issues. For example, in contrast to the preceding example, the following example points to the element with the name country, i.e. <country> :

   link:href="Europe.xml#country"

Also, I can find examples such as the following, which allow you to find an element based on the value of an attribute where that attribute is called id :

   link:href="Europe.xml#country(id)"

And there are things like this where you can also find child sequences (collection elements) based on their sequential positions in the collection:

   link:href="Europe.xml#country(id/2/3)"

Or even this to find a child element in a collection:

   link:href="Europe.xml#id('35').child(4, item)"

The preceding examples contradict the initial example using the id attribute name and are all essentially dependent upon a DTD (Document Type Definition), which can underlie an XML document with a relational database structure. So far in this book I have avoided DTDs and XML Schemas and will continue to do so until the next chapter. Why? Because Chapters 5 and 6 described changing a relational database into a native XML database, using XML data types. DTDs and XML Schemas form a logical mapping between XML and relational database structure. With the advent of XML data types, this method is somewhat out-of-date. Additionally, XPath 2.0 and XQuery 1.0 do not rely on DTDs and XML Schemas, but more or less use XML data as a database (the equivalent of XML data type storage into a relational database). This is why the preceding few examples are somewhat confusing.

You can use XPath functionality and expressions with XPointer. XPath 2.0 is not dependent on the existence of a DTD or XML Schema in order to provide a mapping to a relational database table structure.

In reality, the original XPointer specification was highly complex and unpopular. Utilizing XPath expressions to define XPointer makes perfect sense. The result is utilizing already learned XPath syntax, rather than introducing a further layer of complexity to define XPointers. The following example uses an XPath expression to point to a particular country:

   link:href="Europe.xml#xpointer(//country[name="France"])

The xpointer() syntax must be used, obviously to distinguish XPointer and other syntax definitions such as XLink and XPath itself.

This example finds the name of the city, in the first country, listed under the region of Africa:

   link:href="Europe.xml#xpointer    (/demographics/region[name="Africa"]/country[position()=1]/city/name)

My objective here was not to utilize simple XML document examples in order to demonstrate XLink and XPointer, perhaps too vaguely. The demographics data is semireal world data but it is fairly large. In general, demographics data is relatively static (meaning it changes perhaps on an annual rather than daily basis). In fact, commercial applications performing transactions for customer- facing systems could likely perform hundreds, if not millions, of transactions per second. eBay and eTrade are good examples of database requirements with millions of transactions per second. So my demographics data is not real world on that scale, but compared to XLink and XPointer examples I find online (XML documents with ten lines each), my demographics XML document of 4GB will suffice.

How useful are XLink and XPointer in a real-world scenario?

As with XLink, XPointer is not yet in production (a recommended standard only). XPointer does not work for my version of Internet Explorer (version 6). It is unlikely to work in version 7 either.