|M. David Peterson
Nice write up! Theres only one thing that I disagree with, though only partially,
> XQuery also promises to flatten the tasks of collecting data and arranging it for presentation, because it's a transformation language (with the same capabilities as XSLT) as well as a query language. Instead of having to write SQL to get your data and code in another language that formats it, you can perform both steps in XQuery, if you want.
Unfortunately the transformation portion of XQuery doesn't work from a template perspective. WAY TOO MUCH code rewrite, and/or awkward imports are required to accomplish the reusable aspect that XSLT offers as its defacto foundation.
Use XQuery to gain pinpoint precision access to the data you want, outputting the result in a "Lingua Franca" XML format of your personal choice. I personally think Atom provides a nice envelope format for both the over-the-wire and storage piece of the puzzle, but there are certainly others. In regards to the XML format of your choice, obviously this will be determined by the output needs -- If your documents are all web-based, then XHTML makes a lot of sense. If they're more document-oriented, the ODF or (possibly) OpenXML seem to be good candidates, ODF being the simpler of the two to groc.
With these in place, then converting from one format to another becomes nothing more than using reusable transformation files to convert from the storage format to the desired viewing format.
XSLT 2.0 offers some nice benefits in regards to managing the output into multiple document formats, as well as simplifying various pieces of XSLT (like grouping) that are EXTREMELY complex using XSLT 1.0. But EXSLT offers a lot of the same benefits (excluding multiple outputs as part of the same transformation process, though it wouldn't surprise me to see that change in EXSLT 2.0 if this were ever to become a reality (and I think it will)) and EXSLT has quite a few more implementations out there than does XSLT 2.0, though with Saxon/Saxon on .NET you gain the benefit of both XQuery and XSLT 2.0 as part of the same engine, so I'm not sure if that point is one that can be viewed as any sort of dividing line between whether XSLT 2.0 or EXSLT is the more practical of potential transformation solutions.
Of course, with all of this, this is only my own opinion. There are certainly other opinions, each of which have just as much validity, so for what its worth, there ya have it.
Thanks for the write up, Simon! Tons of great info in here to reference/learn from!
Simon optimistic about XML? Check the weather report in Hades! Watch out for flying pigs!
But seriously ... there seem to be two somewhat contradictory points here -- the rise of JSON and the maturation of XQuery. Doesn't the former undermine the importance of the latter? How can XQuery change the web if the Web consists of tag soup for humans and JSON for machines? Or will the availability of XQuery breathe new life into the "SGML for the Web" vision and we'll see a lot of XML that's worth querying and mashing up with XQuery?
Mike has it right. Simple things tend to become complex when one of the fundamentals have to be optimized. I blogged that topic comparing the evolution of internal combustion engines and the demise of the shade tree mechanic along the way. The surprise for some will be the demise of the 'it must be simple' web developers for whom so much has been sacrificed.
For a decade, we spent our time trying to get SGML accepted by programmers. For our sins, we succeeded, perhaps and the bewildering families of reams of specifications were piled on top of that thin paper that was tossed onto the floor in '96. The secret was that nothing of much importance can be done with something that simple unless the other piles are created as well, or some practical applications are sacrificed.
At this point, I think it's easy to see that the struggle has shifted from web developers vs markup technologies to web developers vs programmers and that is a sea change most have yet to understand or talk about. When the internal combustion engine began to be optimized for weight and fuel consumption, none of the principles (fuel + fire + air in the right combination = power) really changed except 'the right combination' and 'the complexity of the engine needed to make it work. But the knowledge and skills required, the tools required, and the learning curve changed incredibly and the shade tree mechanic became an evolutionary dead end.
I think the big change coming is XAML, not XQuery. What is in play now is where Joe WebPage goes, what tools/objects are required, and if the web as the haven of 'web developer's over professional programmers' is a vanishing niche along with the XML conferences. Note the SGML conferences experienced a similar decline. If it follows the same path, it breaks up into conferences for each middle tier object required for each class of application language. XML knowledge is assumed the same way plumbers assume one can solder; just another tool and technique.