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:

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 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:

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.