XML in the Wild

I had originally planned for the next entry in this blog to be about mousetraps – who’s got the best mousetrap, why is so-and-so’s mousetrap better than your mousetrap, why is my mousetrap better than yours, etc.

That’ll have to wait for another time, because frankly, I’m still turning the subject over in my mind to the point that I’m more likely to rant freely, instead of writing rationally, on the subject... Oh... and I simultaneously endlessly confused and bored my co-worker on the whole mousetrap thing on our way home from XML 2006... Sorry!

I’m glad I waited on the rant – I can always rant another day. In the meantime, I found a much more interesting thing to write about: Jon Bosak’s closing keynote address to the XML 2006 conference, which has just been published over at the XML 2006 Conference Proceedings web site.

I knew I was going to write about this as soon as I read the text. I also know at least one other person has already blogged about specific parts of Jon’s address. Specifically, other bloggers have chosen to address the merits and values of XML-based technologies, and whether or not vendors are hindering the creative spirit that led to XML in the first place. This point, combined with my own recent research, really hit home for me. I had one of those “YES!” moments when I finished reading.

I’ve been doing a lot of reading on the Semantic Web, Information Architecture, and other library science-ish topics lately. Specific titles include Explorer’s Guide the Semantic Web by Thomas Passin and Ambient Findability, by Peter Morville. I had already finished the first book and was most of the way through the second when Jon’s keynote was posted. The keynote started out with a reminiscence of SGML past. Quite naturally, my thoughts started tripping down a sort of Dickensian broth of past, present, and future. But not so much in context of specific technologies or standards. Both Passin’s and Moorville’s books captured my imagination with visions of what computers can do with semantic information in the future – both with and without human input; which of course, triggers the catastrophist side of me to hope that we won’t create the next HAL 9000..., or at least that we learn from our speculative fictional mistakes as well as our real ones...

But I digress. The point is, none of the speculative problem-solving solutions will ever happen if people don’t think past current technology, or totally forget to think creatively about solutions even with the restriction that we are boxed in by what vendors are willing to offer.

Which leads to my big gripe about the XML 2006 conference: There was simply too much focus on technology, and not enough creative business problem analysis. The fact is, when it comes to standards and recommendations, there are already too many technologies and solutions looking for problems to solve. Oh, and the whole idea that each of these technologies and solutions be XML-based in syntax? That may be getting out of hand, too, as other people have started to compare new technologies written in XML syntax to Kudzu. It’s never a good thing when something gets compared to an alien invasive species of vegetation.

Anyone can fight over which technology reigns supreme, and they are welcome to it. But fights generally don’t solve business problems, and one thing I learned as soon as I hopped over the fence dividing the vendor/consultant pool to the customer pool, is that us customers have problems to solve. Ideally, technology should be something that gets applied to solving the problem, after you know what the problem is.

Well, actually, technology is irrelevant and second choice to problem identification and solution until you run into a technology barrier that prevents you from doing things the way you really want. In the real world, creativity does get constricted by vendor-imposed limits. For example, Microsoft Word supports valid custom XML if you attach a W3C Schema to your document. What if you don’t want to use Schema? What if you want to use the other XML features of Word AND still get valid XML without W3C schemas? Yeah, I get that I could write my schema in RELAX NG and transform it to W3C Schema, but the downside of this is that it adds an extra step to my workflow AND doesn’t solve the problem that I needed RELAX NG to solve in the first place, since you can’t create a valid W3C XSD file from a RELAX NG file that effectively breaks the W3C Schema rules. So much for getting around the famous UPA rule (Unique Particle Attribution). I can’t apply thinking about which standards could possibly solve my problem here, because even though I supposedly have a choice in tools, the fact of the matter is that my workflow requires the use of Microsoft Word 2003.

But going back to the “climber up to the guru on the mount” perspective, I totally get what Jon Bosak’s saying. The creative part of what you can do with XML – that is, thinking speculatively about problem-solving (think big picture – semantic web stuff of the future, other ways to manipulate textual content... the list goes on...) with XML-based technology, should not be stifled by what vendors pick and choose to support... It’s up to vendors to look at business problems, AND potential solutions, AND ALL technologies that might contribute to an appropriate solution. It’s up to customers to remember to hold vendors to this task. Just because you’re a customer doesn’t mean you should stop thinking like an early adopter. Finally, it’s up to leaders like Jon Bosak to make sure we don’t forget the past, while working in the present, and dreaming of the future. Good thing he’s there to remind us.

Labels: XML2006

I attended two sessions that discussed schemas this morning. The first presenter was from Microsoft, and he explained how Microsoft decided they needed to know more about how people are actually using Schemas (or if they're using Schemas?) before they went and built a tool to build schemas that people might actually use.

The study revealed recurrent reasons people are currently using schemas:

1. Because other people are using them.
   
2. Because other people are using them and we need to work with their stuff.
   
3. Because the tools don't support DTDs.
   

They didn't ask questions about best practices. They didn't ask questions about business need. They just took the answers from a bunch of developers and DBAs and went from there. Amusingly, they summarized the response:

"Developers are saying that DBAs use schemas, and everyone else says Developers use schemas."

Uhh... Where are the business requirements in this mix? Some context please? No. They didn't ask about that. They just asked about current use.

MKay...

What was established is the fact that the level of schema use will increase in the future as people stop supporting DTDs. More products will incorporate some sort of XML. Other people are doing it, so we need to be on the band wagon. Future projects will require schemas. Web services require schemas.

One thing that wasn't explicitly mentioned – Microsoft never bothered to support DTDs in the first place.

But here's the important stuff – My notes from the Q & A at the end of the session:

Q: Is there any relationship between the adoption of Schema and XQuery?

A: The presenter can't answer this question since they didn't really ask anything about XQuery.

Q: Tools for complicated schemas would be very useful for adoption – people are using tools to build SOA schemas now, which is why people who are developing more complex schemas are building schemas by hand. Will there be tools developed for people who are working with extensible and complex schemas?

A: Presenter says that Microsoft has worked with large schemas and that they want to ensure that their tools/APIs will handle large schemas effectively.

Note: Currently, it's hard to work with modular schemas – the schema include thing is not highly implemented – which means people are flattening their complex schemas just to make them work.

Note from a W3C Working Group Member: The Schema 1.1 workgroup wants to make sure they're attacking a limited set of pain points to repair things that people want – did Microsoft's study tell them anything that might help the Schema 1.1 working group address these pain points? Why are people using Schematron and RELAX NG? What is the schema group missing?

(My un-voiced answer to this question: Uhhh.... go look at what Schematron and RELAX NG do, and you'll find out what XML Schema doesn't.)

I asked if they had asked any questions about methodologies and best practices, since my own attempts to follow methodologies resulted in a schema that Word 2003 chewed up and spit out. I was told that Microsoft's study never asked people about schema methodologies and tool support for how schemas are developed (like schemas in MS Word 2003). However, they are going to try track best practices in the future. A huge barrier to completing this work is getting Web Services group to cooperate with the SQL group and the Office group on what best practices are.

Q: Would the use of UML to develop schema requirements have any effect upon, or help increase the adoption of schemas in the future?

A: Cricket cricket cricket... Uh... No. That wasn't part of the survey.

In conclusion, people use schemas, but not because they want to. A small number of people started a conversation regarding RELAX NG, Schematron, and TRANG during the session break.

The next session was "Daddy? Where do Schemas Come From" – the most I got out of that was practice safe validation. Someone even suggested digitally signed certificates to validate validation. Oh boy.

This presentation also failed to put reasons to practice safe validation into real world business requirements.

Sigh. Hopefully the desktop tools sessions this afternoon will have more relevance in terms of the real world.

Labels: XML2006

For kicks and giggles, I figured I'd try out the blogging capability in Word 2007 for today's post.

What do y'all think?

Probably can't tell the difference, can you. If so, that's good.

Today's activities include the following sessions:

• A Study in the Adoption and Usage of XML Schema - its Design and Results
  
• Daddy? Where do Schemas Come From? Some Facts of Life for Schema Users
  
• The ODF Plugin for Microsoft Office
  
• Panel: Word and Open Office for XML Authoring
  
• Creating Intelligent Workflows with PRISM Metadata
  
• Making the Most of XML with Adobe InCopy and InDesign
  

That's gotta be enough to make my head spin for one day...

Oh! And I found that there's a vendor here who actually says they can transform MS Word or XML into richly formatted, brand consistent InDesign and PDF documents. The company is http://www.typefi.com, and I'm really surprised that I haven't heard of them before now, what with all of the InDesign research I've been doing lately. I'll get back to y'all on this one as soon as I get the scoop on what it Is they actually do...

At any rate, I have just enough time to get another Mocha before this thing starts, so I'm outta here.

Labels: XML2006

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.

Labels: XML2006