Simulación del convertidor CC/CC tipo buck sin perturbaciones

The remainder of this section gives a brief survey over other XML query languages that are relevant to this thesis because they have properties that are interesting for the development of the language Xcerpt. Besides

CHAPTER 3. WEB QUERY LANGUAGES

the languages listed below, there exist many other XML query languages that are not discussed here, e.g. XQL [90] and XirQL [52] (both are similar to XPath), Quilt [35] (the main predecessor of XQuery),

Lorel [2] (which is an extension of the Object Query Language OQL to semistructured data), fxt [17] (the Functional XML Transformer, similar to XSLT), FnQuery [96] (adds XPath-like constructs for querying

XML to Datalog and/or Prolog), XPathLog/LoPiX [75] and X-DEVICE [10] (both are deductive path- based query languages for XML), Elog [11] and CXQuery [38] (the Constraint XML Query Language), are extension of Datalog with XPath expressions, WebLog [68], XML-RL [70] (the XML Rule Language), and XET/XDD [7] (XML Equivalent Transformations). In addition to these pure query languages, there are furthermore the languages XDuce [32] and CDuce [13], which extend the functional programming language

ML by constructs for XML processing, and the library HaXml [121], which adds XML processing support

to the functional programming language Haskell.

All of these languages are textual languages aimed at querying XML or semistructured data. Besides this, a number of visual query languages exist (e.g. XML-GL [33], Xing [47], Complete Answer Aggregates [76], BBQ [78], QURSED [84], VXT [86], and Lixto [12]) that allow to compose query programs using a visual interface. Since visual querying is not the focus of this thesis, none of them are described here in detail. Furthermore, a number of query languages aiming at querying Semantic Web data are proposed (e.g. RDQL [95], OWL-QL [48], and TRIPLE [99]), which are not capable of querying plain XML data and thus also not discussed here.

UnQL

UnQL [31] (the Unstructured Query Language) is a query language originally developed for querying

semistructured data and precedes the development of XML. It has later been adopted to querying XML, but the origins are still apparent in many language properties (for example, UnQL has a non-XML syntax that is very similar to the syntax of OEM presented in Section 2.1.3). UnQL uses query patterns and construction

patterns and a query consists of a singleselect ...where ... rule that separates construction from querying. Queries may be nested, in which case the separation of querying and construction is abandoned.

Example 3.2 (UnQL)

Select all authors and titles of books written after 1991 and return them inresult elements contained within aresultselement. Note the use of nestedselect ...where ... statements to group titles and authors.

select { results: (

select { result: { title: T,

( select { author: A }

where { author: A } in Book ) }

}

where { book: Book } in Bib,

{ year: Y, title: T } in Book ) }, Y > 1991

where { bib: Bib } in db

Since UnQL has originally not been developed for the Web, it is apparently not possible to address arbi- trary Web documents. Instead, the example above uses an identifier calleddbto refer to the semistructured database represented by the documentbib.xml.

Pattern-Based Querying and Simulation. UnQL is to the best of our knowledge the first language to propose a pattern-based querying (albeit with subqueries instead of rule chaining) for semistructured data (including XML). It furthermore uses graph simulation as its foundation for evaluation, which inspired the usage of simulation for the evaluation of Xcerpt.

3.3. EXISTING WEB QUERY LANGUAGES

XML-QL

XML-QL [45] is a pattern-based, rule-based query language for XML designed at AT&T Labs. Like UnQL,

it uses query patterns initiated byWHEREand augmented by variables for selecting data and construction

patterns initiated byCONSTRUCT for reassembling selected data in new structures. An XML-QL query always consists of a singleWHERE-CONSTRUCT rule, which may be divided into several subqueries. The following example gives a flavour of how XML-QL queries are constructed using nested subqueries. Like in XQuery and XSLT, expressions beginning with $are variables. Note also that XML-QL uses tag- minimisation to abbreviate closing tags.

Example 3.3 (XML-QL)

Select all authors and titles of books written after 1991 and return them inresult elements contained within aresultselement. Like in UnQL, subqueries are used to group titles and authors.

WHERE <bib>

$book

</> IN "bib.xml" CONSTRUCT <results>

WHERE <book year=$y> <title>$t</> <author>$a</> </book> IN $book, y > 1991 CONSTRUCT <result> <title>$t</> WHERE $a2 IN $a CONSTRUCT <author>$a2</> </result> </results>

Logic Variables. One of the main characteristics of XML-QL is that it uses query patterns containing multiple variables that may select several data items at a time instead of path selections that may only select one data item at a time. Furthermore, variables are similar to the variables of logic programming, i.e. “joins” can be evaluated over variable name equality. Since XML-QL does not allow to use more than one separate rule, it is often necessary to employ subqueries to perform complex queries.

XMAS

XMAS [72], (the XML Matching And Structuring language), is an XML query language that builds upon

XML-QL. Like XML-QL, XMAS uses query patterns and construction patterns, and rules of the form

CONSTRUCT ...WHERE .... However, XMAS extends XML-QL in that it provides a powerful group-

ing construct instead of relying on subqueries for grouping data items within an element. It furthermore

supports pattern restrictions that allow to restrict the admissible bindings of a variable.

Example 3.4 (XMAS)

Select all authors and titles of books written after 1991 and return them inresult elements contained within aresultselement. Note that XMAS provides special grouping constructs for grouping titles and authors and thus avoids nested subqueries.

CONSTRUCT <results> <result> $T $A {$A} </result> {$T} <results>

CHAPTER 3. WEB QUERY LANGUAGES WHERE <bib> <book year=$Y> $T: <title/> $A: <author/> </> </> IN "bib.xml" AND $Y > 1991

Grouping Constructs. In any kind of tree or graph structured databases, it is desirable to group data items beneath a node in the construction of the result. For example, when constructing the list of authors with all titles in the example used in this Section, it is necessary to group allresultelements that can be created for different authors beneath theresultselement. Likewise, it is necessary to group all book titles of an author beneath theresultelement corresponding to that author.

Many query languages (like XQuery, UnQL, and XML-QL) implement grouping by reverting to sub-

queries that are embedded in the construction pattern, which leads to a close intertwining of query and

construction patterns (as shown in the examples for XQuery, UnQL, and XML-QL above). In contrast, languages like XMAS (and Xcerpt) provide high-level grouping constructs that allow to collect data items that are bound in a separate query pattern. Such grouping constructs usually specify a set of variables on whose bindings the grouping is performed. A data item is created for each different combination of bindings for these variables.

In XMAS, grouping is expressed by enclosing the variables on whose bindings the grouping is per- formed in curly braces and attaching them to the end of the subpattern that specifies the structure of the resulting instances. In Example 3.4 above, aresultelement is created for every instance of$T(indicated by{$T}after the closing tag of the elementresult). Within every such result element, all authors are collected (indicated by{$A}).

When comparing this XMAS query with the XML-QL query above, it is easy to see that grouping constructs that result in a separation of querying and construction are a desirable property for a query language, as the query is more declarative and therefore easier to grasp.

Pattern Restrictions. A pattern restriction restricts the admissible bindings of a variable to such data items that match a certain query pattern. In XMAS, pattern restrictions may be attached to variables in the

WHEREpart of a rule and are denoted by:, followed by the restricting pattern. In Example 3.4 above, the variables$Tand$Aare restricted to certain patterns.

Arguably, a pattern restriction is a very declarative means to specify restrictions for variables. In lan- guages that do not support pattern restrictions, it is necessary to add the restriction by using additional external constraints that are not part of the query pattern, and thus break up the query pattern. As a conse- quence, queries in such languages are not only less concise, but often also less efficient to evaluate.

Part II

The Language Xcerpt

CHAPTER

FOUR

Xcerpt: A New Programming Paradigm for Querying the Web

This Chapter introduces the syntactical constructs of the language Xcerpt and gives an intuitive meaning to them based on many examples without immediately providing the formal definition. Similar descriptions have also been published in [23, 93]. More extensive examples can be found in the next chapter.

This Chapter is structured as follows: Section 4.1 describes two different syntaxes that are available for Xcerpt programs, one based on XML and the other using a more compact term syntax. Section 4.2 describes data terms, which are Xcerpt’s means to represent semistructured data and closely resemble the semistructured expressions of Section 2.1. Section 4.3 introduces query terms, which are patterns used to select subterms from data terms by binding variables. They resemble data terms, but provide advanced constructs for querying. Section 4.4 formally describes matching of query with data terms and introduces the notion of ground query term simulation, which is central to this thesis and replaces the syntactical equivalence used in most standard pattern matching approaches. Next, Section 4.5 describes how query terms can be combined to form more complex queries. Section 4.6 then introduces construct terms, which serve to reassemble variable bindings gathered in queries into new structures. Of particular interest here are the powerful grouping constructs all and some that serve to create nested lists of subterms. Finally, Section 4.7 introduces construct-query rules that combine queries with construct terms.

4.1

Two Syntaxes

Xcerpt uses two different syntaxes for programs and semistructured data, an XML syntax and a compact term syntax (called the Xcerpt syntax). The XML syntax allows to use standard XML tools like parsers, editors or browsers (in particular, the visXcerpt prototype [14, 16, 15] is based on a rendering of the XML syntax in Mozilla). The Xcerpt syntax, which is used in most parts of this thesis, is a more compact representation of Xcerpt programs. It is more convenient for both presentation and editing of Xcerpt programs. Furthermore, to emphasise that XML is not the only representation format for semistructured data (see Section 2.1 above), the Xcerpt syntax also provides a more generic format with a deliberate abstraction from XML. The XML syntax of Xcerpt is not presented in this thesis. Regular updates are available athttp://www.xcerpt.org.

Besides such “convenience features”, the Xcerpt syntax allows to express language constructs that have no direct counterpart in XML and thus can only be represented in the XML syntax by using Xcerpt-specific attributes and elements:

• graph-structured data: Semistructured data is in general graph structured (cf. Section 2.1). While

several linking and reference mechanisms for XML exist (e.g. XLink [110] and ID/IDREF [116]), they privilege hierarchical data, as all of them need explicit dereferencing.

In contrast, references in Xcerpt terms are treated as equal to a parent-child relationship when match- ing a query pattern against a “database”.