Debunk the myths and misconceptions of XQuery

XQuery brings a lot of hope to software architects and developers because it dramatically reduces the amount of code that needs to be written to create a service that uses XML. You might think that what XQuery is doing is easy to understand, but there are still misconceptions and misconceptions in the XQuery software development community. Frank Cohen analyzes and clarifies in detail the many mysteries and misconceptions surrounding XQuery.

If you are using XML, a Web, or a service-oriented architecture (oriented Architecture,soa), you will most likely benefit from the development of XML Query (XQuery) standards. Although XQuery has not yet been approved as a formal standard, there are dozens of implementations that help software architects and developers every day. The emerging XML document query criteria include the next generation of XML Selection language (XPath 2), XML serialization, Full-text retrieval, and functional XML data modeling. There are many myths and misunderstandings to be uncovered in projects of this scale. Here are some common myths and misconceptions surrounding XQuery.

　　 Misconception: Database companies view XQuery as a direct competitor to their core business

The database company sees XQuery as an opportunity to complement its core solution.

For software architects and developers, XQuery increases productivity and agility. Tool vendors are eager to support XQuery in a reasonable sense.

For developers, XQuery is much like SQL and naturally compares the two. Moreover, more and more data are using XML tags, which forces database companies to increase the ability of XML storage, persistence, and querying in their products. XQuery has so many developer support that IBM and Oracle put their rivalry aside, and instead expanded their core database offerings to provide XQuery capabilities.

Database companies have also seen the opportunity to be the first to take full advantage of XML-formatted database vendors (and ultimately become market overlords). The data that is currently stored in the relational database is normalized by row and field. In the XML world, each row contains an infinite number of fields, each of which is part of the parent/child hierarchy. The first vendor to deliver high performance and XQuery flexibility will win a huge new market.

One evidence is that XQuery unites IBM and Oracle (no longer a vicious adversary), partnering to set up JSR 225 (see Resources), XQuery API for Java (XQJ). On the. NET side, Microsoft and IBM have jointly submitted an XQuery test package to the World Wide Web Consortium (WWW).

　　 myth: XQuery will replace XSLT

Both XQuery and XSLT have enough developer support to coexist. In fact, the development of the latest specifications for XQuery 1.0 and XSLT 2.0 is sequential.

The intersection of XQuery and XSLT lies in the problems they solve: XML data transformations, XML collection federated, and XML data advanced queries. Developers will still see arguments about the two technologies, including myths and misconceptions of all kinds. For example, I've often heard that XQuery can query multiple different source files at once, so it's much superior to XSLT. In fact, the XSLT 2.0 handler allows multiple nodes to be given in an input queue. XSLT 1.0 has the document () function that allows you to access multiple source files in one transformation, and XSLT 2.0 also supports the new collection () function. I have often heard that XQuery syntax looks better, but lacks pattern matching for XSLT template styles. Although this may be true, I firmly believe that XQuery will also increase this functionality. Ultimately, developers can expect improvements and competition from both technologies to make them comparable in functionality and capability.

Finally, there is the problem of a developer's mental retardation. The XSLT conferences that I attended made me feel that I didn't really understand it. The translation syntax for XSLT does not have the main () or Start method typically used in Java and Jython. I sometimes think of XSLT as a script that doesn't really understand XSLT. The XQuery looks like SQL and solves a lot of questions that I have to rummage through the shelves for answers.

　　 myth: XQuery will replace SQL

XQuery is best for XML, just as SQL is best for relational data. XQuery provides SQL-like query capabilities for applications that require access, selection, integration, and transformation of one or more XML collections. Although XML enthusiasts may consider everything in the world to be encoded with XML tags, the single relational database model is still entrenched, and most of the world's digital data is encoded using Yukeng and column tables. SQL does not disappear quickly. In contrast, an XQuery extension has been shown to treat the results of the SQL call as part of an XML document collection.

As noted above, XQuery is like SQL for relational databases for XML. Sometimes, however, XQuery is easier to use than a relational database. For example, for a generic developer, it is much more complicated to use SQL to create a multiple-form outer join query for a new XML document than to write XQuery.

The popularity of XML has forced the Standard group workgroup to extend the SQL specification to incorporate XML processing capabilities. The sql/xml standardization of SQLX Group, INCITS H2 Group, and ISO/IEC JTC1/SC32/WG2 is working to extend the SQL standard to enable it to process XML data.

　　 misconception: Using XQuery must give up procedural programming and turn to object oriented programming

For XQuery, the procedural scripting language is the same as the Object-oriented programming language. If you are willing to write PHP scripts, you can still continue to do so. Most of the existing programming languages have XQuery implementations.

The benefit that XQuery brings to developers is that it reduces the amount of code needed to execute the query. Sometimes relational data is in two or more databases, and developers need to generate reports to display two of databases. Developers who like to use a procedural programming language such as Python may want to write 100 or more lines of code to retrieve, parse, and process data. Of course, you can write a few lines of XQuery to do it.

　　 Myth: XQuery is more difficult to use than JDOM, JAXP, and other XML parsing APIs

XQuery is no more difficult to use for XML data than XML parsing APIs. JDOM, JAXP, and other XML parsing APIs provide Java code and methods for processing XML data. Many object-oriented design patterns are prepared to write objects that deal with the complexity of XML documents. Writing Java objects takes time, effort, and specialized skills. Any subtle changes in the underlying XML data format require that objects be modified. Proponents of XQuery can safely say that XQuery scripts can quickly discover the XML data that an application needs to represent, as opposed to writing Java objects using JDOM. In addition, many XQuery libraries provide Java interfaces, so you can write XQuery code in a Java class to get a result set, just as you would call a method. Then let the Java class handle the results.

　　 Myth: XQuery is hard to learn

Software developers who use Java,. NET, and other languages find XQuery easy to learn. XML has a number of less beautiful parts, including those inherited from the early SGML standard. XQuery uses a neat set of commands to easily process XML. While it is difficult for the General Staff to master XQuery, the learning curve is not steep or long.

[1] [2] Next page