WWW/Internet - Portal do Software Público Brasileiro

ISBN: 978-972-8939-25-0 © 2010 IADIS3. XLPATH SPECIFICATIONIn this section, the language proposed will be presented. In Section 3.1, the requirements identified as a guideto XLPath specification are given. In Section 3.2, we will discuss two approaches to perform queries used inXLPath. In Section 3.3 the language syntax and semantic are detailed.3.1 XLPath requirementsFrom the need verified regarding the navigation over links, as well as XLink conceptual approaches, it ispossible to compile a series of requirements have guided the XLPath construction: i) Conceptual distinctionbetween arcs and connections, and the elements that define them – From XLPath point of view, an arc ora connection must be taken as an “act” of an element refer another, through a label present in the attributesfrom and to of XLink, or through an URI in the href attribute. Thus, it is correct to affirm that, whenregarding queries based on this language, an arc may start from an element locator to an element arc, or viceversa.;(ii) Navigation in different levels of abstraction – The main purpose of a query language over linksis allowing the navigation through the network formed by the existing references between distinct elements.However, references through URI (href) constitute the only possible path between two elements that referthemselves in this way. Thus, XLPath must provide the option of abstracting these connections, decreasingthe quantity of steps necessary to reach the query final purpose; (iii) Approach for simple links as theirextended equivalents – Aiming to avoid a very long syntax, XLPath must be capable of navigating oversimple links based on the same syntax used for extended links. To do so, this language must start from anapproach that assimilates the simple links as their extended equivalents; (iv) Identification of implicit arcs –In situations in which links are declared without the occurrence of arcs, or that, in the occurrence of them, theattributes from and/or to have been omitted, XLPath must be capable of identifying the occurrence of implicitarcs, maintaining, thus, the conformity with the XLink specification; (v) Similarity with the XPath syntax –The language proposed here for navigation over links must have the maximum possible number ofsimilarities with the XPath syntax, in order to facilitate the assimilation for the users. (vi) Conditions forqueries refinement – Placed that may exist an arbitrary number of links referring a given element, XLPathmust enable refinement conditions to be applied to the query, in order to allow the distinction among thedifferent elements that constitute these links, starting from their names or values of attributes; and (vii)Absolute and relative path, and query performed in steps – Just like it happens in XPath, XLPath followsthe concept of query in steps, where each step selects a list of nodes that is passed as an input parameter forthe next step until the execution of the last step and obtainment of the final result. The initial step may startfrom a document root (absolute path), or from a specific node in its interior (relative path).3.2 Graphical viewOne way of analyzing how the structure formed by extended links may be explored by a query language isrepresenting it graphically. We suggest two different approaches to represent the links, Low Level Approachand High Level Approach. These approaches are exemplified through a link illustrated in Figure 1, adoptingthe symbolism presented in Table 1.Low Level Approach: The low level approach offers a detailed view of the link, considering all theelements involved in the existing references, which includes locators, arcs and resources. The advantage ofthis approach for a query language is to allow the access to all these elements. Figure 3 shows the link ofFigure 1 represented in low level. To differentiate elements of the same kind and with the same name,numbers corresponding to the order in which each element appears in Figure 1 are used as labels.High Level Approach: In an extended link, a type locator element has the function of being the localrepresentation of certain remote resource. Due to it, for each remote resource there will be only one locatorreferring it. The high level approach offers a simplified vision of the link, where the locators are omitted andthe arcs make direct reference to the correspondent remote resource. For a query language, it would result inthe formulation of simpler queries to do a link crossing (when we navigate from one resource to anotherpassing by the link). Figure 4 shows the representation in high level for the link shown in Figure 1.92