Monday, December 04, 2006
Paths and Queries and Transforms... Oh My!
So today's action was the XPATH 2.0, XQuery and XSLT 2.0 Explained tutorial, taught by Priscilla Walmsley.
Priscilla Walmsley is a name I've heard before. Or at least a name I've read before. I have the Definitive XML Professional Toolkit edition that she edited with Goldfarb. I also have the XML in Office 2003 book that she co-wrote with Goldfarb.
She's written quite a few books on things related to XML, and she hangs out with Goldfarb. This is a woman who knows her stuff. Forward, backward, and upside down, since she's also written books on XML Schema AND sits on W3C working groups.
That said, I think the most valuable part of the tutorial came 7 pages before the end of 114 pages of material.
What, huh? 7 hours to get to the one hour of stuff that REALLY REALLY matters?
Yep.
The last hour was dedicated to the topic of deciding which technology to use - the new, and sexy cool XQuery - a language to make the hearts of SQL lovers everywhere go pitter-pat, or XSLT 2.0... the very verbose and somewhat confusing (is it declarative or functional? What do you mean it's both?!?) transformation language that is currently the workhorse of all XML workflows requiring you to actually do something with your XML after you're done with the presentation stuff and have uploaded to your repository.
Don't worry. I haven't forgotten about the XPATH part. It goes in between XQuery and XSLT. XPATH isn't quite XQuery, but it's definitely useful in XSLT, and the 2.0 version of the candidate recommendation has added a lot of stuff that was sorely missing from previous versions. Stuff that I will let you go search out for yourself, rather than go all pedantic on you.
Back to the reason why the last 7 pages were the most important...
The business decision to use XQuery or XSLT is, as are most decisions regarding which technology to use, a matter of BUSINESS REQUIREMENTS. yep. That's right. Same old, same old. It comes down to what you're trying to help your business accomplish.
XQuery looked all nice and cool and SQL-like, and more human-readable, and we spent most of the day discussing the various ins and outs of query construction. Yeah, we covered some overview stuff at the beginning, and some XPATH stuff in between, but we really spent most of our day looking at XQuery examples.
Six hours in, we switched from XQuery to XSLT 2.0, and looked at the nifty new features that make the 2.0 version a great improvement over the 1.0 version - Grouping, Sequences, Temporary Trees, MULTIPLE RESULT documents, and other stuff. Very cool - and more stuff you can go read all about at the W3C website, among other places.
OK... Back to the business requirements...
The fact of the matter is, XSLT is the language you want to use when your XML is not regular. Not predictable. Not data. Huh? Not data? Yeah. XSLT is the language you want to use when your XML is text. It was drummed into me early on in my XML life, that while all data was text, not all text was data. A very important distinction that I have passed on to pretty much every training class and presentation audience I've stood in front of.
Not all text is data.
Which means XQuery, as cool and simple as it is (besides the fact that it's all shiny new - OK - relatively new), is not the tool for processing narrative text.
Fact of the matter is, even though there's a serious overlap in capabilities between the two languages, you just aren't going to beat XSLT's capability to handle highly variable, presentation-oriented, and heavily recursive XML content. In short, don't fix what ain't broke. And don't move to the newer and cooler stuff because it's newer and cooler.
XQuery is a language for querying XML databases. It doesn't matter if that database is a fancy RDBMS, or an XML document. What does matter is that XQuery is dependent on predictably structured pieces of content that behave. You can slice and dice content from multiple sources, you can make new documents, but it's all predicated on content that has the regularity of data.
Text doesn't behave. Text isn't regular. Text can't be forced into a nice neat jello mold that you can produce over and over again.
I hadn't really compared the 2 standards before today, but now that I have, I plan to spend more time reading up on XSLT. Despite all my attempts to work in the world of data - the Access and SQL Server database training and implementations of my past - I work best with text. And while I really prefer to play with text in a graphic design environment, I do understand how structure implied by, or semantically applied to, text, makes it easier to do the graphic typography thing.
Conclusion: XQuery is very cool. I enjoyed learning about it. I just don't see a place for it in my immediate business activities when XSLT is standing behind me, beckoning enticingly with the giant Michael Kay Wrox books that I've purchased, but have yet to really study...
Then again... maybe there's a place for XQuery in the stuff that helps us process our narrative text... like maybe on the XML produced by an InfoPath form? Hmmm. I'll have to think about that.
In the meantime, dinner beckons, and I need cool my proverbial CPU for the remainder of the day.
I'm outta here.
Priscilla Walmsley is a name I've heard before. Or at least a name I've read before. I have the Definitive XML Professional Toolkit edition that she edited with Goldfarb. I also have the XML in Office 2003 book that she co-wrote with Goldfarb.
She's written quite a few books on things related to XML, and she hangs out with Goldfarb. This is a woman who knows her stuff. Forward, backward, and upside down, since she's also written books on XML Schema AND sits on W3C working groups.
That said, I think the most valuable part of the tutorial came 7 pages before the end of 114 pages of material.
What, huh? 7 hours to get to the one hour of stuff that REALLY REALLY matters?
Yep.
The last hour was dedicated to the topic of deciding which technology to use - the new, and sexy cool XQuery - a language to make the hearts of SQL lovers everywhere go pitter-pat, or XSLT 2.0... the very verbose and somewhat confusing (is it declarative or functional? What do you mean it's both?!?) transformation language that is currently the workhorse of all XML workflows requiring you to actually do something with your XML after you're done with the presentation stuff and have uploaded to your repository.
Don't worry. I haven't forgotten about the XPATH part. It goes in between XQuery and XSLT. XPATH isn't quite XQuery, but it's definitely useful in XSLT, and the 2.0 version of the candidate recommendation has added a lot of stuff that was sorely missing from previous versions. Stuff that I will let you go search out for yourself, rather than go all pedantic on you.
Back to the reason why the last 7 pages were the most important...
The business decision to use XQuery or XSLT is, as are most decisions regarding which technology to use, a matter of BUSINESS REQUIREMENTS. yep. That's right. Same old, same old. It comes down to what you're trying to help your business accomplish.
XQuery looked all nice and cool and SQL-like, and more human-readable, and we spent most of the day discussing the various ins and outs of query construction. Yeah, we covered some overview stuff at the beginning, and some XPATH stuff in between, but we really spent most of our day looking at XQuery examples.
Six hours in, we switched from XQuery to XSLT 2.0, and looked at the nifty new features that make the 2.0 version a great improvement over the 1.0 version - Grouping, Sequences, Temporary Trees, MULTIPLE RESULT documents, and other stuff. Very cool - and more stuff you can go read all about at the W3C website, among other places.
OK... Back to the business requirements...
The fact of the matter is, XSLT is the language you want to use when your XML is not regular. Not predictable. Not data. Huh? Not data? Yeah. XSLT is the language you want to use when your XML is text. It was drummed into me early on in my XML life, that while all data was text, not all text was data. A very important distinction that I have passed on to pretty much every training class and presentation audience I've stood in front of.
Not all text is data.
Which means XQuery, as cool and simple as it is (besides the fact that it's all shiny new - OK - relatively new), is not the tool for processing narrative text.
Fact of the matter is, even though there's a serious overlap in capabilities between the two languages, you just aren't going to beat XSLT's capability to handle highly variable, presentation-oriented, and heavily recursive XML content. In short, don't fix what ain't broke. And don't move to the newer and cooler stuff because it's newer and cooler.
XQuery is a language for querying XML databases. It doesn't matter if that database is a fancy RDBMS, or an XML document. What does matter is that XQuery is dependent on predictably structured pieces of content that behave. You can slice and dice content from multiple sources, you can make new documents, but it's all predicated on content that has the regularity of data.
Text doesn't behave. Text isn't regular. Text can't be forced into a nice neat jello mold that you can produce over and over again.
I hadn't really compared the 2 standards before today, but now that I have, I plan to spend more time reading up on XSLT. Despite all my attempts to work in the world of data - the Access and SQL Server database training and implementations of my past - I work best with text. And while I really prefer to play with text in a graphic design environment, I do understand how structure implied by, or semantically applied to, text, makes it easier to do the graphic typography thing.
Conclusion: XQuery is very cool. I enjoyed learning about it. I just don't see a place for it in my immediate business activities when XSLT is standing behind me, beckoning enticingly with the giant Michael Kay Wrox books that I've purchased, but have yet to really study...
Then again... maybe there's a place for XQuery in the stuff that helps us process our narrative text... like maybe on the XML produced by an InfoPath form? Hmmm. I'll have to think about that.
In the meantime, dinner beckons, and I need cool my proverbial CPU for the remainder of the day.
I'm outta here.
Labels: XML2006
// posted by Jean K. @ 5:46 PM 
