Nobody Asked Me, But...
August 27, 2003
This month, I begin the fourth year of writing XML.com's "XML Q&A" column. I'd like to thank my editors here for continued support and indulgence; at no time is that indulgence more evident than in August, when I tackle questions that no one has, to my knowledge, actually posed. In other words, every August I answer questions I just feel like answering.
Q: Is "knowing XML" worth anything anymore?
I mean basic XML. A few years ago I crammed my head with everything XML-related that I could find; it all used to fit -- if not in my head, at least between the covers of a 300- or 400-page book. It was interesting and exciting. It all made an exhilarating kind of sense.
Then the real world intruded. At work nobody knew anything about XML, and non-XML project priorities couldn't wait. One thing and another happened in Real Life, and I stopped reading the XML mailing lists. I stopped playing with XML software. I stopped buying XML books. Coming back to XML recently was a shocker: I recognize the names of many of the key players, but it's like being at a cocktail party where everybody's speaking Esperanto.
So, did I waste my time? Is just knowing XML in general any good anymore?
A: The short answer to both questions: Probably not.
The long answer depends a great deal on what you want your knowledge of XML to achieve. Whatever that might be, if you've truly been away from XML for a couple of years, you've got a lot of catching up to do -- so much catching up, in fact, that you may decide it's all not worth it. The comedian Steven Wright once said, "There's a fine line between fishing and standing on the shore looking like an idiot". If all you plan to do is watch the floodwaters of XML rush by in the vague hope of snagging something useful, you're probably on the wrong side of that line.
If you're no closer to XML in your work than you ever were (and have no plans to switch jobs), you've got two basic choices:
-
Continue your dilettantish ways. Resubscribe to a couple of mailing lists, and lurk for a month or more while you pick up jargon and contexts that you're unfamiliar with; brush up on the status of the specs which were current when you stopped paying attention; acquire some software (open source or commercial; experimental or well-established) and noodle around with it a bit. This will be a fun way to get back into the ongoing XML conversation, but not necessarily "worth anything" unless it leads to the next choice, to wit:
-
Select a specialty. Go deep instead of broad.
It's true that there are people -- many if not all of them participants on the XML-DEV list -- who are apparently profoundly smart about nearly everything going on in the XML world; many of them grew up with and are still fond of SGML, Smalltalk, Lisp, and awk, yet are equally at home discussing Java, XML Schema, Unicode, web services, Perl, the Campaign for Real Ale, and the handling characteristics of the Segway. Face it, though: you are not one of those people.
There's just too much going on, and it's going on in too many places at once, for you to get it all. If you knew and were comfortable with XSLT back in the good old days of 2000, for example, then dive back into it now. You'll have to pick up some new things (especially, in this case, with the imminent arrival of XPath and XSLT's 2.0 versions) but the basics will still be familiar. And once you've regrounded yourself, select another related specialty... Repeat until satisfied. The idea is to learn one thing at a time; go on until your head feels ready to explode; stop and recenter; and continue (or not) as long as you want.
But forget about being a jack-of-all-trades XML generalist again; those days are long gone for anyone who can't "do XML" full-time or more.
Q: So then what's a good XML specialty?
Hey, I liked your answer to the last question. You kind of glossed over one point, though: which specialty should I pick? There must be a thousand of them. Just on the W3C list of specs alone, there are hundreds -- nearly all of them XML-related. Factor in all the vendors involved in implementing them, plus the standards embraced by other organizations (OASIS, IETF, and so on), and selecting just one specialization to start with -- let alone a whole series of them over the long term -- seems impossible.
A: It does, doesn't it?
Naturally, I can't answer your question in any way guaranteed to be right for you. One lackluster approach would be to pick a handful of XML-related buzzwords or acronyms that seem interesting to you -- SVG, SOAP, and SMIL, say. Then run each through Google, and select the one with the most hits; at least that way you know you'll have plenty of company should your newcomer's misery become unbearable. Or you can subscribe to general-interest technical/business periodicals; if they feature some XML-related technology, chances are it's "hot", at least for a while.
It would be mentally healthier, though, just to find something inherently interesting to you and stay with it. Down the left-hand menu of any page on XML.com, you'll find a list of topics. Spend an hour or two just browsing -- even an hour or two a day for a few days running. Something will suggest itself to you.
Personally, if I could outline my dream XML job, it would have something to do with XSL-FO and something to do with Python (neither of which I've ever had enough time to explore as much as I'd like) -- maybe even both. But I've no idea at all whether those are potentially lucrative choices or "good XML specialties" in any other regard. Don't take my own preference as your own.
Q: Aren't you going to cover "hiding XML" this month?
The last couple of years in your "Nobody Asked Me..." column, you included hypothetical questions about obfuscating XML -- making it apparently meaningless -- using some kind of code or encryption scheme. Aren't you going to continue that this year?
A: You're referring, I guess, to the XSLT snippets which I demonstrated to "encrypt" a document's content and markup using a simple ROT-13 technique. As I said at the time, ROT-13 is not a particularly good encryption scheme and hardly worth investing in if you really want to render your XML meaningless (let alone if you need true security); all I was really doing with those columns was indulging a perverse sense of humor to turn the tools of XML (XSLT) against one of XML's own design goals (#6, "XML documents should be human-legible and reasonably clear"). And along the way, readers might learn some things about XSLT that they didn't already know.
But an ability to encrypt XML documents is critical for many applications. The W3C itself has addressed this in numerous specs at one level or another of completion, including these (the quotations are from each document's abstract):
-
XML Encryption: "This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data."
-
XML Signature: "This document specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere."
-
XML Key Management: "This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the proposed standard for XML Signature [XML-SIG] developed by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and an anticipated companion standard for XML encryption."
XML.com has covered many of these issues, too, with articles including:
-
Bilal Siddiqui's recent series on Web services security (Parts 1, 2, 3, and 4)
-
Last year's "Privacy and XML" series, by Paul Madsen and Carlisle Adams (Parts 1 and 2)
-
"An Introduction to XML Digital Signatures," by Ed Simon, Paul Madsen, and Carlisle Adams
Other good references include Robin Cover's page of information and links regarding the OASIS Security Assertion Markup Language (SAML); the University of Siegen's XML Security page; and the Apache Project's XML Security site.
|
|
|
Also in XML Q&A |
|
But that old perverse instinct of mine hasn't rolled over yet. More recently, I've gotten interested in applying the principles of steganography to XML. Steganography (from the Greek, meaning loosely "covered writing") is the practice of hiding information in such a way that the information doesn't even appear to be there in the first place -- generally by embedding the information within wholly innocent content. Contrast this with encryption, which (with its meaningless strings of characters or words) virtually cries out for attention from cryptographers, "Hey! There's something secret here! Bet you can't figure it out!"
(Stego, as it's sometimes called, has become politicized recently in the battle between publishers of digital content, like the RIAA, and that content's consumers. Ironically, stego can be used by both sides in the battle -- think "an MP3 hidden inside a JPEG" as well as the more conventional "the copyright holder's signature hidden inside the recording". Furthermore, it's given rise to a whole new art form, steganalysis -- the detection of a "steganographed" chunk of digital content. But I'm not taking a political position here.)
To trigger your imagination about how an XML document's "meaning" could be well (and annoyingly) hidden, visit the decidedly non-XML-related SpamMimic site; try encoding a simple document like the following:
<document>Peek-a-boo!</document>
Next month it's back to the real world of real XML questions. Thanks for reading.