I’ve been introduced recently to XQuery, particularly it’s strength in applying transformations to XML-based data.
The implications for sites with a dynamic backend, such as one that builds XML from queries, is huge! Potentially, XQuery can add, admittedly a new layer of abstraction, but also a new way to markup if not style this data before it’s revealed to the frontend!
IBM’s developerWorks has published an article on this subject, principally discussing how XQuery could be used to (in the above fashion) create styles as the entire presentation “layer” of a “web app”, using the Model-View-Controller working-pattern:
One morning, while you browse through your e-mail and sip your daily dose of coffee, your manager pops into your office and informs you that you must deliver the corporate Web site, fishinhole.com, in a language-agnostic manner. He also informs you, with apparent glee, that not only must you deliver the Web site with language independence in mind, but you must also retain the MVC pattern. Then he mercifully turns around and leaves.
Having read through it once, I was initially confused why Java would be used as the controller, when JSF / JSP could probably do the whole job (the app’s already on a Tomcat server). Thankfully there was an explanation:
It’s also important to note that an outstanding requirement of this application is to respond to user input with limited page refreshes. This is currently done with an Ajax implementation. You realize that this is a non-negotiable point from the marketing department, so you also continue with the Ajax implementation.
Using the XQJ API, the queries can also be spawned, in their entireity, from this setup.
Following down the English syntax, the listing for the J in this AJAX shows a DIV element as its hook, so it only refreshes the table-rows required. Frontend code created like this is the one big reason I think AJAX implementations will help prove how invalid markup is irrelevant in today’s web development, to everyone’s detriment. The author does however raise the point that sometimes time-constraints mean “…things happen quickly rather than properly”. “Props” to that.
My IBM reference has also published an earlier article discussing the usefulness of XQuery 1.0 in comparison with XSLT 2.0; the W3‘s other transforming XPath offshoot. One might say that XSL-FO (also related to XPath as much as ye olde XML) does bigger and better things than either with outright styling efforts, but it seems only one of these will “make the cut”. W3Schools’ infographic‘s quite useful in both these regards…
I’ll let this author say it:
By design, XSLT 2.0 and XQuery 1.0 have a lot in common. Both languages are based on the same foundation: XPath 2.0. Both languages are intended to manipulate XML documents. Both languages borrow from the script concept of using interpreted language for simple tasks.
For a cogent paradigm in action see script.aculo.us. To continue:
In practice, you could use either (XPath-based) language to achieve a given result. One is not more powerful than the other. And yet, each language has a distinct personality. I suspect that, depending on the task at hand, and maybe depending on your personality, you might be more at ease with one or the other, so it is worth learning about them [both].
While the article is a little sparse on nitty-gritty, it does show how very different the given code can look for a text-based developer: the XQuery example is much shorter, but affectively acts as a filter on the document (the second listing after the jump); while the XSLT is clearly there to apply a “catch-all” or “trolling” iterative way to reveal the document’s data without displaying the code. Using this train-of-thought, it is easy to separate which “dialect” of XPath is being used for which “layer” of a website. In this case (bending the M-V-C idiom!) the Document of RSS is the Model and the XSLT is the View; the XQuery can be said to provide the Controller. Logic, Content and Style would be less techie terms. Nonetheless, both really do overlap somewhat; there can be only so many syntactical differences between two languages with a very close parent. As the author notes more than once, their use can entirely be down to the developer’s choice, presuming they have a solid grasp of each.
On a tangent, this makes me wonder…
- The distinct unlikelihood of XHTML 2.0 reaching the top of the W3’s to-do list soon (in favour of HTML5)
- and the apparent lack of staff according the W3 XML Activity (as of today)
…if one of the above will be replaced, or phased out? For example, I struggle to find a recent hard-copy in-depth examination into XSL-FO, even though those at renderX and at ZVON‘s old site are good steps, what if I wanted to write this stuff by hand (apparently I’m mad)? Crane Softwrights Ltd. has achieved publishing, and with O’Reilly having made an edition, perhaps I shouldn’t complain too loudly lest work stops altogether!
I’m going to refer again to the W3 now: their opinion (on Styling technologies) is to focus at “…CSS when you can”. XSL (the eXtensible Stylesheet Language) should take second place.
Is this to be a niche market (for tutorials, publications and debuggers / IDEs)? Perhaps when HTML5 and CSS3 do finally take off, there will be a greater focus on these arguably more practical technologies (for the burgeoning client-side developer). However there is undoubtedly a place for XML as well, as I stipulated waaaaay back at the beginning of this English syntax. After all, there are allegedly Great Things happening with Apache’s “XML Project” like XSP; and RDF has done quite well for itself off the back of RSS.
It appears I am not the only one to ruminate, although Matt Zumwalt appears a little less astride the do / do-not “fence”. I think I can safely raise the phrase “personal choice” as a sub-text again, but he does discuss yet another XML-related topic that appears to have hit the doldrums of development…
Roll on the Technical Author’s Award to go to an XML book!