WWW/Internet - Portal do Software Público Brasileiro

ISBN: 978-972-8939-25-0 © 2010 IADISBry and Eckert [2005] also propose and extension of XLink for linkbases processing in the Web. Theyintroduce the concept of interface for links structure and a linkbases management mechanism. This proposalis different from XLPath in the purposes, because, while XLPath is proposed as a navigation language forlinks based on elements and attributes defined in XLink, Bry and Eckert proposal suggests a way ofmanaging linkbases in the Web. The proposal described by Lizorkim [Lizorkim et al., 2003 and 2005, and S-exp, 2009] suggests an extension of XPath. Despite of this solution be similar to XLPath, because it is anextension of XPath, its implementation is performed based on expressions S, a native type in the functionallanguage Scheme. This requires the conversion of XML files to the SXML format, a representation of XMLInformation Set in S-expression form. The SXPath proposal refers to the implementation of the XPathlanguage to manipulate links in the functional language Scheme. Thus, in the SXPath approach, there isinitially the conversion of the XML document to SXML. Like occurs in XLPath, it is possible to highlight thecoherence that exists between the data structuring form (DOM and S-expressions) and their manipulation(Java and Scheme). However, to reach this coherence, SXPath needs to convert the XML format in SXML,which, in spite of being similar, results in an additional effort. Ahmedi [2001 and 2005] proposal was basedon the protocol LDAP (Lightweight Directory Access Protocol) to make a query, through XPath expressions,XML documents interconnected with links of the type XLink. As LDAP has a data model different fromXML, XML documents with the links need to be mapped for this model. A similar solution, proposed byAhmedi and Arifaj [2008], there is no need for mapping for a data model different from XML. However,XPath queries, in this proposals, are based on the xlink:href attribute, not exploring all the power of semanticexpression of XLink, i.e., the queries processing do not consider the semantics attributes of XLink (title, rolee arcrole), the behavior attributes (show e actuate), or the values for the xlink:type attribute (resouce, locator,arc and title).XLink Processor (XLiP) is a Fujitsu implementation [XLip, 2005] to extract XLink and XPointerinformation in XML documents. Based on Java and DOM, enables the use of all types of links expressed byXLink. However, diferently from XLPath, it is owner. Other commercial solution to deal with XLink, basedon Java and DOM, it is Batavia XBRL Java Library (BXJL) [Batavia, 2009], it is however specific tomanipulate only XBRL documents. Java XBRL API Implementation [XBRLAPI, 2008] is an open codeproject that provides an XLink processor for XBRL documents. This processor is a solution based on SAX,manipulating XLink events. Another approach based on SAX is XLink Filter [Laurent, 1998], which createsa links collection that may attend to applications requires to identify which elements contain links, as well astheir purposes and behaviors. SAX usage has the advantage of being more efficient regarding memory use,but is not a solution standardized by W3C. XLinkit [Nentwich et al., 2000] is a tool to generate linksaccording to rules and verify the documents consistence. As an entrance, the tool receives a group of XMLdocuments and a group of potential rules that connect these documents contents. The rules representconsistence restrictions among the resources. XLinkit conduct back a linkbase with a group of links XLink,which allow the navigation among the resources elements.In XSPath [Cavalieri et al., 2008], the notion of queries performed through steps, present on XPathexpressions, is extended in order to allow the navigation through the connections contained in the schemethat associates the elements, specified in XML Schema documents, to their data types, being also possible tonavigate inside data complex types [W3, 2010]. However, there is not always the interest in explore a datacomplex structure. Therefore, XSPath offers two different navigation approaches: low level expressions,which analyze complex types intern structures, and high level expressions, which steps do not depend on howthe element are combined to form complex types.According to the study of these proposals, to attend the navigation in XML documents interconnected bylinks, some solutions require a transformation in the XML document, as the proposals based on SXML, theLoPiX, and the one which defines three navigation modes in linkbases (transient, temporary and permanent),others are limited to specific solutions, such as the ones for XBRL and the XLinkit. Java XBRL APIImplementation and XLink Filter are funded by the use of SAX, what restricts its application, since SAX isnot a W3C pattern. Besides, none of these solutions are specified as language for navigation in links of theXLink type. XSPath is a proposal of language for navigating in XML Schema documents, which served as abase of the high and low level approaches for XLPath queries proposed in this paper. Table 5 presents someresults derived from the comparison among the proposals discussed in this section and XLPath. This analysisis made considering the capacity for links manipulation. It is settled that XLPath manipulates any type of linkbased on XLink and that it does not require any change on the original XML documents. Besides, XLPath isan open code solution and based on patterns W3C (DOM, XPath, XML Schema and XLink.) and it is a98