Professional XML Databases phần 5 ppsx

Relational References with XLink 359 We discussed the title and the behavioral attributes when we talked about simple links. The new ones are arcrole (which we come back to later) and the traversal attributes. The to and from attributes are used within the arc itself to show directionality. As a value, these attributes take the value of the label attribute of the resource or element type elements. In our last example, we defined the resource that represented our home with a label of myhouse: <HOME xlink:type="resource" xlink:href="home.xml" xlink:label="myhouse"/> Now, let's modify our earlier extended link so that we have to go to two different stores on our ROUTE: the GROCERY store and another resource called BOOKSTORE. Because arcs are describing generic behavior, if you use the same label on different resources, the arc will define a relationship between all the elements with the same label. If we make the label for both stores a generic "store" we can see how the arc is extended. The changes have been highlighted here: <ROUTE xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended" xlink:title="A sample extended link"> <HOME xlink:type="resource" xlink:label="myhouse" address="123 Main St."> I live in my home </HOME> <GROCERY xlink:type="locator" xlink:href="food.xml" xlink:label="store"/> <BOOKSTORE xlink:type="locator" xlink:href="books.xml" xlink:label="store"/> <GETSTUFF xlink:type="arc" xlink:from="store" xlink:to="myhouse"/> </ROUTE> The traversal of links now defined allows both the bookstore and the grocery store to be linked into "myhouse". We can see this in the following diagram: Home xlink:label="myhouse" Bookstore xlink:label="store" Grocery xlink:label="store" When we define an arc with the to and from attributes, this creates a traversal rule. Each traversal rule will explicitly set the behavior for a set of resources. Thus, it is significant to note that each arc element within an extended link must define a unique traversal rule. This makes sense, because once it is possible to traverse a certain direction from one resource to another, there is no need to define that traversal path again. Chapter 9 360 If you need to set a rule that you can get from resource A to resource B, then you can only set that rule once. Remember though that directionality is explicit, so that if we switch the to and the from attribute values: <RETURNSTUFF xlink:from="myhouse" xlink"to="store" /> we have a different unique traversal rule, even though the same resources are in play. If we need to set a rule that you can go from Resource B to Resource A, this is different from before, and we would require a new rule. Home xlink:label="myhouse" Bookstore xlink:label="store" Grocery xlink:label="store" However, if the from or to attributes are absent from the arc element, then all resources in the extended link are assumed to be in play. In other words: <STUFF xlink:type="arc"> This would be a legitimate arc for our example above that would accomplish the same thing as the <GETSTUFF/> and <RETURNSTUFF/> arc elements, along with providing a traversal between the store elements themselves. Home xlink:label="myhouse" Bookstore xlink:label="store" Grocery xlink:label="store" Relational References with XLink 361 It would be illegal according to the XLink rules to define <STUFF/> in the same extended link as the other two, because <STUFF/> makes the other two repetitive. If we have defined rules for getting from Resource A to Resource B, and for getting from Resource B to Resource A, we cannot also define a rule which allows us to move in both directions. The resource-type Element The resource-type element is used for local resources in the extended link. Note here that there is a distinction between local and remote resources. Remembering back to the last example, the type of our HOME element was resource, while the stores' type was locator. <ROUTE xmlns:xlink="http://www.w3.org/1999/xlink" <HOME xlink:type="resource" ></HOME> <GROCERY xlink:type="locator" /> </ROUTE> HOME represented a local resource, while the stores represented remote resources. In the resource element the link itself, along with any content of the link, is considered to be a local resource. It takes the following attributes: Semantic: ❑ role ❑ title Traversal: ❑ label The local resource can be both a starting resource, and an ending resource in the same extended link. I hinted before at the possibilities for inbound links, and their magic starts here. If we put some meaningful content into our resource element: <HOME xlink:type="resource" xlink:label="myhouse" address="123 Main St."> Go west on 5th until you come to Main St. Go east on Main St. to 123. I live on the 5th floor. </HOME> We can give our arc some behavior: <GETSTUFF xlink:type="arc" xlink:from="store" xlink:to="myhouse" xlink:show="embed" xlink:actuate="onRequest" /> Chapter 9 362 We have now done something neat. We have told our XLink application to display the directions to my house embedded in the current document when a person viewing a store resource clicks on the route. Consider an application that is set to load an XML document called orders.xml. The orders document contains a route element for every location contained in a database of customers. Furthermore, the route elements have been written with the same arcs, to reference the order information documents for each type of store. If a user were to request the orders.xml document, our application would load each store resource document into a temporary file either on disk, or in memory. This would be based on the XLink aware application recognizing that food.xml and books.xml are remote resources as defined by the locator-type elements. After each remote file has been loaded, its contents could be scanned for placeholders we have set. In this case, we might be working with a document we own, and can structure any way we like, but it will be read-only when parsed by our application. If we take one of the remote resources, food.xml, and give it the following structure: <Food> <Store type="Grocery"> <Order id="383232" location="myhouse"> <Item id="232" name="milk" /> <Item id="565" name="cheese" /> </Order> </Store> </Food> then we could build our application to key on the location attribute in the <Order> element of each remote resource. The application can then insert the defined link at each place in each store resource document where a match for the label myhouse occurred, effectively attaching directions to each store order. Then, a final document containing all the information of the remote resources could be displayed to the user. This may be hard to visualize since we don't have such an application, but consider this possible interpretation: Relational References with XLink 363 This display would be possible if an application were to display the extended link element names and attributes. As you can see, myhouse can be linked to from both store elements. If the user were to click on the myhouse element with the arc defined above they would get: The document loaded for the user is not any one of the resources we have been working with. The user has asked to view the orders.xml document, which is nothing more than a placeholder for customer information. This customer information has been made useful via inbound links from documents containing order information. The orders.xml document as displayed appears to contain all of this information in one place. In actuality, it has loaded two read-only resources in the background, and enhanced their display with the local customer information. The locator-type Element As we have seen, the locator-type element is the remote resource being defined by the extended link element. It can take four attributes: Semantic: ❑ role ❑ title Locator: ❑ href Traversal: ❑ label There is only one mandatory attribute, href, which must have a URI value specified. However, the mere presence of an href attribute value does not give the locator element linking behavior. Chapter 9 364 Remember that it is the arc element that provides the linking behavior, and that the arc element uses the value of the label attribute to define the link. If a locator is missing from the label attribute, it simply cannot be identified in an arc, although it may still be useful to an XLink application as a descriptive element. However, it cannot participate in any XLink specified link It is the locator element that gives the extended link a lot of its power because it is able to identify resources that may be outside the control, or scope, of the document defining the link. If an arc identifies a traversal rule between two locator elements, it is creating a third-party link. Third- party links are two or more remote resources being linked by a local document's linking element. The ability to describe links from remote resources provides a special arc called a linkbase. Linkbases Special collections of remote resources identified with locator elements can be defined with a locating linkbase. Linkbases are a special type of arc definition, which allows for simplified management of remote resources. You specify this special arc with the arcrole attribute set to the following: xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" If we have numerous remote resources we would like to relate to one another, it may be simpler to hold each of these links in one document that can be loaded by our local documents. This could be useful for: ❑ Creating a reference between documents you don't own ❑ Annotating documents written by others ❑ Maintaining a central link repository for easier maintenance For example, imagine we had a number of stores, and all of them should be able to link to or from a shopping list. Rather than defining all of these stores inside of our particular extended element, we can load a pre-set listing of stores with a traversal rule for getting from stores to myhouse. In order for the XLink application to make use of these links, we define a linkbase arc that has the listing of links as the ending resource. A linkbase must be written as a well-formed XML document according to the W3C candidate recommendation. This makes sense because the linkbase document will be processed in order to retrieve the extended link information contained within. In this way, if I have several remote resources that may all traverse to or from stores, not just my shopping list, then I can re-use the store resources again and again without putting all the stores in each extended linking element. <ROUTE xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended"> <HOME address="123 Main St." xlink:type="locator" xlink:label="myhouse" xlink:href="house.xml"> All Stores </HOME> Relational References with XLink 365 <STORES xlink:type="locator" xlink:href="storelinks.xml" xlink:label="allstores"/> <GROUPOLINKS xlink:type="arc" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:from="myhouse" xlink:to="allstores" xlink:actuate="onRequest"/> </ROUTE> Here, within our ROUTE, we have: ❑ HOME – which refers to a document that contains the directions to my house ❑ STORES – the locator, which specifies list of stores that I might wish to shop from, which points to the linkbase document. This is not a participating link resource. The document that it specifies will provide the link participants. ❑ GROUPOLINKS – which specifies the special arcrole attribute. The arc with this special arcrole will load the extended links in the document specified by the labeled locator listed as the ending resource in the arc. Consider the following diagram: Whatever the contents of the storelinks.xml file, the extended links contained within will be pre- loaded when the orders.xml document is loaded. The links defined there are then available for the orders.xml document to use. This is a convenient way to locate each resource required for processing the orders.xml document before anything is displayed for the user. It also provides a way to keep the stores listing separated from the orders.xml document. Chapter 9 366 The storelinks.xml document, which is the linkbase document, may look like this: <?xml version="1.0"?> <LINKS xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended"> <GROCERY xlink:type="locator" xlink:href="groceries.xml" xlink:label="store"/> <BOOKSTORE xlink:type="locator" xlink:href="books.xml" xlink:label="store"/> <CLOTHING xlink:type="locator" xlink:href="clothes.xml" xlink:label="store"/> <UTILITY xlink:type="locator" xlink:href="electricity.xml" xlink:label="store"/> <PLACESTOSHOP xlink:type="arc" xlink:from="store" xlink:show="new" xlink:actuate="onRequest"/> </LINKS> in this case, a single extended link allowing all stores to traverse to the house.xml document. Notice that in this case, the to attribute has been left blank in order to relate all of these store locators to all resources in the orders document. However, the links within a linkbase can specify any traversal rule, even if this requires re-processing the originating document (orders.xml) to handle the links. When orders.xml is loaded, the only item to show for the user may be a link that says "All Stores". It would be upon selection of that link, that the stores information would become available. This would differ from the earlier example, which would have loaded all of the store resources along with directions right at load time. Note that linkbases are not to be traversed. That is, they provide a document a list of links that may be traversed, but when linkbases themselves are loaded, they are only providing information to the document about the location of remote resources. This means that the show attribute is irrelevant in a linkbase. The actuate attribute is still relevant because we may not want all the links to show up until the user has asked for them. Using Extended Links Before we move on, let's be sure we have a good picture of extended links by looking at a full example. We will look at the example of an invoice in XML. The invoice document contains some standard elements such as item, invoiceid, customers, and directions to a particular customer's location. The attributes from the XLink namespace have been added to the various elements such that we now have the following XLink types: Invoices.xml Element Name XLink Type Link Location Invoice Extended Link Description Title invoiceid local Resource resource local – in document item remote Locator resource /inventory/items.xml customer remote Locator resource /contacts/customers.xml directions local Resource resource local – in document getdetail Arc Relational References with XLink 367 Here is the DTD for the XML invoice, so that we can work with a validated XML document, and get the benefit of writing the actual elements in a more simplified manner as well (ch09_ex1.dtd): <!ELEMENT invoice ((description|invoiceid|item|customer|directions|getdetail)*)> <!ATTLIST invoice xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED> <!ELEMENT description ANY> <!ATTLIST description xlink:type (title) #FIXED "title"> <!ELEMENT invoiceid ANY> <!ATTLIST invoiceid xlink:type (resource) #FIXED "resource" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:label CDATA #FIXED "invoiceid"> <!ELEMENT item EMPTY> <!ATTLIST item itemid CDATA #REQUIRED qty CDATA #REQUIRED xlink:type (locator) #FIXED "locator" xlink:href CDATA #REQUIRED xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:label NMTOKEN #FIXED "item"> <!ELEMENT customer EMPTY> <!ATTLIST customer customerid CDATA #REQUIRED xlink:type (locator) #FIXED "locator" xlink:href CDATA #REQUIRED xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:label NMTOKEN #FIXED "customer"> <!ELEMENT directions ANY> <!ATTLIST directions xlink:type (resource) #FIXED "resource" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:label NMTOKEN #FIXED "directions"> <!ELEMENT getdetail EMPTY> <!ATTLIST getdetail xlink:type (arc) #FIXED "arc" xlink:arcrole CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show (new|replace|embed|other|none) #IMPLIED xlink:actuate (onLoad|onRequest|other|none) #IMPLIED xlink:from NMTOKEN #IMPLIED xlink:to NMTOKEN #IMPLIED> Chapter 9 368 Remember, you can type this in if you want the practice, or you can go and download it from the web site for this book along with all of the other sample code: http://www.wrox.com. The DTD provides the necessary structure, and gets some of the mundane details down in one place. This will be more important as you go to implement this in the real world, because unlike our example you would likely be generating numerous instances of the same element type. That being said, here is the XML document (ch11_ex1.xml): <?xml version="1.0"?> <!DOCTYPE invoice SYSTEM " ch11_ex1.dtd"> <invoice xmlns:xlink="http://www.w3.org/1999/xlink" xlink:title="Invoice Detail for Order number 123456"> <description xlink:type="title"> Customer Details for Invoices</description> <invoiceid>123456</invoiceid> <item itemid="9876" qty="500" xlink:href="/inventory/items.xml" xlink:title="items on customer invoice"/> <item itemid="4321" qty="25" xlink:href="/inventory/items.xml"/> <customer customerid="765423" xlink:href="/contacts/customers.xml" xlink:role="http://sample.bigwarehouse.ex/customer/invoiceref"/> <directions>Turn left from warehouse, drive 5mi. on route 3 to Johnson. Turn left onto Johnson and continue to Main St. </directions> <getdetail arcrole="http://sample.bigwarehouse.ex/invoice/details" xlink:show="replace" xlink:actuate="onRequest" xlink:from="invoiceid"/> </invoice> While this XML document is well formed and valid, it is not likely that such a document would stand- alone in the real world. Rather, this would be a single invoice in a list of invoices in a document. As we'll see in the next section, a document like this could easily represent the data in a table from a relational database. Before we move on I would like to note a few features of this example. Notice the use of the title attribute as well as the title element. <invoice xmlns:xlink="http://www.w3.org/1999/xlink" xlink:title="Invoice Detail for Order number 123456"> <description xlink:type="title"> Customer Details for Invoices</description> The proliferation of titles throughout XLink may seem like overkill, but consider that the attribute may be rendered as something like a tool tip for the invoice link, while the title-type element may be used for the entire resulting document. [...]... Chapter 10 Consider the following XML: (55 5 )55 5-1212 (55 5 )55 5-1213 (55 5 )55 5-1214 (55 5 )55 5-12 15 (55 5 )55 5-1216 (55 5 )55 5-1217 (55 5 )55 5-1218 (55 5 )55 5-1219 (55 5 )55 5-1212 Steps 2 and 3 are then repeated for each location in the first location set, with all of the additional ranges being added to the result So, as a result of the XPointer above, we would end up with the following pieces of XML selected in our document: (55 5 )55 5-1212 (55 5 )55 5-1214 R15L5 ... element in the location set on the left name="John"/> name="David"/> name="Andrea"/> name="Ify"/> (55 5 )55 5-1212 For each location in this second location set, XPointer adds a range to the result, with the start point at the beginning of the location in the first location set, and the end point... this list of XLinks: 376 Other Technologies (XBase, XPointer, XInclude, XHTML, XForms) < ?xml version="1.0"?> R15L5 In our new example, we have used the XML attribute xml: base to identify the base or root URI: xml: base="http://acme.mfg.com/invoice .xml/ " Note the trailing / at the end This is essential with XLink, but not with HTML This allows our new XLink: xlink:href="#itemkey(17)" to resolve to http://acme.mfg.com/invoice .xml# itemkey(17) This is the... then query that dataset using XML Query to expose our target Let's look at an example from the previous chapter again: < ?xml version="1.0"?> R15L5 ... xlink:href="acme.mfg.com/invoice .xml# itemkey(14)" xlink:label="item"/> R5L6 R13L3 R15L5 . That being said, here is the XML document (ch11_ex1 .xml) : < ?xml version="1.0"?> <!DOCTYPE invoice SYSTEM " ch11_ex1.dtd"> <invoice xmlns:xlink="http://www.w3.org/1999/xlink" xlink:title="Invoice. XLink 371 <itemlocation xlink:type="resource" xlink:label="location" itemkey=" 15& quot;> R5L6 </itemlocation> <Item xlink:type="locator" xlink:href="acme.mfg.com/invoice .xml# itemkey( 15) " xlink:label="item". about XPointer in the next chapter on other XML technologies, or in the book Professional XML, also by Wrox Press (ISBN18610031110). We know that ch09_ex1 .xml should be the starting document resource