XML
The enduring value of XML literacy
24 FEB 2006 18:08 EST (23:08, GMT)
I've said it before, I'll say it now, and I'm sure I'll say it again before I'm dead: Basic XML literacy is something that no serious IT professional should be without. Notice please, that I say "no serious IT professional" rather than the more restrictive and perhaps obvious sub-class to which "any serious programmer or Web professional" might belong.
Why do I say this? I actually addressed one important reason in one of my earlier blogs this week: If you poke around on any modern desktop or server PC and search for files that end in an .xml extension, you'll immediately see that lots of configuration files, OS patches, updates, service packs and all kinds of software environment settings and information have the darndest way of showing up in XML files nowadays. This means that even garden-variety IT grunts (this means YOU Mr. or Ms. system or network administrator) will benefit if they can open, inspect and understand what they're seeing inside those files.
It ain't rocket science, either. All you really need is an appreciation for the basic meta characters (<, </, >, /> and so forth), simple XML document structure, basic element syntax and a few other odds 'n' ends and you're pretty much ready to rock and roll. I file this diatribe (or rant, if you prefer that term) as my final blog because I want to make the point that XML touches everybody in IT whether they recognize it or not. And thus also, my contention that some basic XML literacy will be helpful to all those who labor in the halls, back room and trenches of information technology wherever they may be.
Having just urged professionals to dig in, let me follow up by recommending some good places to start online and in print. Though there are many more sources to which you could turn, here are some that I've used myself and recommended to others with good results that continue to this day (and I invite anybody who cares to share other nonpareils to e-mail them to me for a later update to this blog in a forthcoming XML tip).
- W3Schools have long offered good markup language coverage across the board; their XML tutorial is as good as anything else they offer. The "XML Basic" section nails the necessary subject matter clearly, cleanly and completely.
- Norman Walsh was one of the original architects of XML and has been a beneficial markup maven for more years than I can remember. His 1998 piece for XML.com A Technical Introduction to XML aims at those who know something about markup languages already, but remains one of the best overviews and introductions I've ever read.
- XMLfiles.com is another great source of basic (and more advanced) XML information; check out the XML Basics Table of Contents there to see what I mean.
- Any book by Elliotte Rusty Harold on XML is bound to be a good one, but my favorite basics book is one he co-authored with W. Scott Means. It's called XML In a Nutshell, and it's now in a third edition published in September 2004. Easy to read and a delight to use, it's a great title to start anybody's XML library.
I could go on and on in this vein, but this is plenty for anybody who wants to learn enough to establish basic literacy. Careful though: XML is interesting, absorbing and leads down lots of interesting paths. Don't get too distracted, but do enjoy yourself! And, of course, if you're already an old XML hand yourself, maybe you can recommend some of these materials to others who could benefit from their contents… Just write in your suggestion.
--Ed--
Posted by Ed Tittel
Venturing ever higher up the protocol stack with XML
23 FEB 2006 19:04 EST (00:04, GMT)
So far, my XML blogs have tended to waltz around two important aspects of the subject matter. On the one hand, as a devoted tools geek and markup fanatic, I like to learn and talk about cool tools and interesting XML applications or specifications. On the other hand, as somebody who's concerned that this technology be something more than flashy toolbox full of gleaming widgets of little interest to anybody other than other widget fanciers, I like to think about the whys, wherefores and ramifications of XML -- or what some wags like to call the "8th layer of the ISO network reference model/protocol stack" -- namely politics and religion, where faith and beliefs dictate behavior and allegiances more than merely technical concerns ever can.
The most interesting aspects of any technology usually occur at this 8th layer and involve the way in which it's actually used, which may even occasionally appear to or actually conflict with how it was intended to be used. Certainly, this is where the level of who's backing a particular proposition or application inside a company or organization has as much or more impact than the technical nuances inherent in the underlying tools and technologies involved. But as anybody who's ever had to design and sell a system inside an organization can tell you, the nuances of backing, involvement of key insiders, movers and shakers, and finding a way to fit into prevailing norms and beliefs are probably every bit as important (and very often, one heck of a lot more sensitive and difficult) than mere matters of markup, features and functions, or technical merit.
Thus, the more you work with XML and the greater your involvement in using this representational mechanism to design and implement systems, the more important it becomes to be able to tell others what XML is, what it can (or should do) and why it even matters a little bit or a lot. That's why keeping in touch with fundamentals and staying attuned to business concerns such as return on investment, increases in productivity, reducing total costs of ownership and other concerns is also important.
No matter how cool the technology is, if you can't get its use funded it's basically irrelevant. Another way that true XML heads might find useful when thinking their way through this exercise is as a rigorous transform of what's important to you into the frame of reference that applies in the management suite. That's why appealing to streamlining processes, improving productivity, easing future migrations -- and ultimately the master credo of "it saves time and money" -- are important to ponder when selling XML solutions to those who must not only buy into the technology, but pay for it as well.
--Ed--
Posted by Ed Tittel
The interesting state of XML security
22 FEB 2006 20:39 EST (01:39, GMT)
Not without irony or accuracy, an ancient Chinese curse may be translated as follows: "May you live in interesting times." I believe the intent of the curse is to inflict unusual, disruptive and -- who knows -- maybe even devastating events on its recipients. When life is interesting, it's also usually fraught with peril, uncertainty, conflicting interests, confusion and other potentially unsettling things. My use of the adjective "interesting" in its application to XML security is therefore intended to describe a chaotic, fragmented and unsettled state of affairs, but also one that is full of truly interesting developments (in both the technical and political dimensions) as well.
Take a quick look at the XML Focus Topics Web page on XML Security at the W3C, and you'll quickly see what I mean. Though the foundation sounds pretty simple and straightforward -- the page puts it this way: "There are generally two primary requirements for sending XML data securely over the Internet: encryption to keep confidential information private, and digital signatures to provide authenticity, integrity and non-repudiation." Straight out of any basic information security textbook, right?
But the devil, as they say, is in the details, and the interesting parts are nicely, but subtly, brought out in the structure of the rest of that Web page, which indeed does a good job of leading interested readers and XML aficionados into this highly interesting subject matter:
- XML Security Tutorials and Articles: Mixing resources from the W3C's own pages, Robin Cover's excellent repository of XML information and wisdom at the CoverPages, the odd vendor white paper from outfits like Verisign and Entrust, plus all kinds of tutorials and how-tos on securing XML, signing on using the XKMS specification, securing Web services and more.
- XML Security Toolkit: With pointers to the IBM XML Security Suite and the Entrust Toolkit for Java, developers can find code, libraries and information on how to use secure XML markup and facilities in their client, server and distributed application code.
- XML Security Specifications: These include both the W3C specs as well as the OASIS SAML specification and the now-defunct S2ML Web site (this is part of how things get interesting). There are 9 specifications mentioned in all, at least one of which (S2ML) is apparently either moribund or defunct.
What does this really say about the state of XML security? A completely pragmatic outlook is to determine which specifications are supported in the XML security toolkits and concentrate your efforts in those areas, because that will ultimately be the easiest stuff to build and use. But it's probably wise to keep an eye on other specifications as well, just in case new functionality they cover becomes mandated by law or regulation, or advisable for reasons of prudence and asset protection (two other fundamental principles of information security, alas all too often overlooked).
--Ed--
Posted by Ed Tittel
On choosing a specification/standard/markup language
21 FEB 2006 16:13 EST (21:13, GMT)
A recent response to a user query of the "this XML application or that XML application?" (let's call this X vs. Y) variety got me to thinking about the pros, cons and costs of adopting any specific XML specification, standard, recommendation or other quasi-definite form of description for business development and use. In the final analysis, if you've got data you need to capture, represent and share, some XML-based form of notation is going to help you get things organized and structured and can't help but make them more accessible. This has the benefits of moving idiosyncratic records and/or documents structured into formats that are well described and (hopefully) well understood, easily accessible and easier to store, update and share.
If worst comes to worst, as I reminded the person posting the X vs. Y question, once you pour data into an XML container, you can always use XSLT and a little elbow grease (or a lot, depending on the complexity of the syntax and structure, and the degree of variance in the data set) to turn one form of XML markup into some other form of XML markup. The only tricky part, of course, is when representation X omits some data that representation Y requires -- in that case, simple transformation has to be augmented by necessary data insertions and life can get more difficult in a big hurry. But even then, moving from one known form and format to another known form and format is a lot less challenging than reworking your entire infrastructure on an as-needed basis.
This is ultimately what makes XML both interesting and useful: The politics of adoption are every bit as important as the nuts and bolts issues of clean, regular syntax and capturing the right data semantics. In the long run, no standard lasts forever, but the data just goes on and on!
Posted by Ed Tittel
In Windows XML pops up in the most interesting places and does startling things
20 FEB 2006 20:26 EST (01:26, GMT)
Just for grins, I decided to search the contents of my hard disks to see what kinds of XML files I could find. I executed a search on "*.xml" to identify all files that end in the extension .xml in the hopefully not-too-unreasonable belief that most such files would indeed contain XML content. That expectation turned out to be correct, and turned up all kinds of interesting items and elements. Let's take a look at some interesting examples I turned up:
-
EVO0.xml: CyberLink's software status information, this little widget includes the product name (PowerDVD), version information, build number, serial number, upgrade information and an installation package driver.
-
Jobs.xml: reflected a boatload of job listings I'd apparently picked up while writing a career advice column for TechTarget at some point or another, but the file was undated.
-
book.xml: contained the structure and layout of Certification Magazine's Web site and a bunch of interesting tracking data that the site apparently maintains about its visitors. It also had an interesting associated file named crossdomain.xml that instructed my browser to permit access from numerous other domains besides the certmag.com domain.
-
Outlook.xml: maintains all kinds of information about my default Outlook program window include history data, folder layout and more. Lots of other Office components, including the Office Updater, also maintain all kinds of search, access and status information in XML files as well.
-
Config.xml in my Skype subdirectory includes information from my Skype address book, timeout and activity status and settings, plus lengthy details about the configuration of how active address entries should appear inside the user interface -- looks like lots of interesting data in here.
-
WMSDKNS.XML is associated with Windows Media Player and sets up all kinds of protocol-related priority and timeout values for multiple streaming protocols likely to be used within its windows. You'll find a lot of good nuts-and-bolts information about how Windows Media Player is set up to access the Internet on your machine, and what kinds of things it can do, through a little careful perusal of this file.
- All shortcuts to recently accessed files and directories also show up in this listing, because Windows apparently creates .xml files in which to store such data (even though XML isn't part of the name for most of these shortcuts, they show up in this generic listing anyway, which leads me to conclude that Microsoft stores this data in text files with an .xml extension, even though it doesn't show them as such). Of the 652 objects that showed up in response to this search request, 149 of them fell into this category all in the
...Documents and Settings\<username>\Recent folder.
Digging into XML on your Windows system can have fascinating results and can be quite informative about applications and services running on or accessible to your system. If you try a little poking around of like kind on your machine, you'll probably be equally surprised by what you find and learn. In fact, if I can talk my editors at SearchWebServices.com into letting me research this further, I think it will make a great series of tips!
Posted by Ed Tittel
The problem of logging and XML
17 FEB 2006 19:05 EST (00:05, GMT)
If there was ever a general class of problem that prima facie appears amenable to XML-based implementations -- if not outright markup language solutions -- it would be the set of problems related to capturing, maintaining, securing, parsing and reacting to the contents of logs of many kinds from those created by the event and security managers so commonly embedded within operating systems and to the many logging facilities built into applications and services (not to mention the servers who provide them).
You'd think this would be a tailor-made case of "looks like a job for XML" with all kinds of attendant specifications and implementations. And indeed I can find ample reference to specific types of logs (associated with Web servers, operating systems and major applications such as databases and so forth). But aside from a few now-abandoned efforts to use XML to bring order to the chaos that still surrounds what's involved in describing, creating, securing and working with logs of all kinds -- such as the Log Markup Language (LOGML) and the Extensible Log Format (XLF) initiative, both moribund since 2001 -- I can't find much by way of general, broad specifications that logic alone might lead one to expect.
"Why is this?" you may ask. Well, log formats not only abound, they are many and incredibly varied. The rough consensus that drives so much meaningful work in standards bodies like the IETF and the W3C hasn't apparently congealed sufficiently to permit this large and potentially tractable problem from assembling the critical mass of interested researchers needed to get some ideas together and start the process of hacking out suitable markup going forward.
To me this shows many problems that XML probably could handle, often go begging and continue to be subject to thousands of fragmented, incompatible formats and solutions simply because the will and energy necessary to create order out of chaos is lacking from one reason or another. This also shows that XML at its best represents a collective will to get something done, or to make useful things happen. Now if only the urgency to clean up logging and a few other computing tarballs I could think of would develop, many good things could happen in those areas, too!
Posted by Ed Tittel
XML keeps popping up all over
16 FEB 2006 16:54 EST (21:54, GMT)
I write a lot of software reviews as part of what I do to make a living. I've added a question to my standard repertoire when talking to software makers and marketing mavens in the past year. This question often comes out as "How does your product use XML?" but is sometimes stated as "What does your product do with XML?" Nearly every vendor I ask this question to not only knows a good answer, but many of them go on to explain how they use XML in one or more of several ways. The most common answers to this question include the following:
- For anything having to do with configuration. XML's incredibly regular and straightforward syntax makes it easy to build, parse and check configuration data, and is often seen as a big win by those who build software that absolutely requires such data to work.
- For anything having to do with logging, event or trace capture. In this case, formal descriptions of meta data and verbose, but unambiguous, methods for creating plain text files that map to data structures and information of sometimes staggering complexity offer capabilities that vendors find simply irresistible. This is true not only because the same logs work on readers or analysis tools on different platforms, but also because it's easy to transport and exchange such logs and then to filter or transform them as needed (push one button, slide some data into a database for records retention, push another button, get a pretty colored graph, all from the same data).
- Any time data needs to move from one program or machine to another, XML is hard to beat. This is especially true when clients and servers need to interact or when client agents work locally on behalf of some central data repository and console application elsewhere on a network. Here again, regular, straightforward, well-documented markup helps make data easy to encode and package for transmission, simple to deliver and validate and equally simple to absorb and digest upon receipt. And then there are the many options for checksums, digital signatures, encryption and so forth that standard XML security specifications also make available.
For a long time, I kept thinking it was cool that XML popped up inside the files that Microsoft uses to distribute service packs or security updates, inside various network management tools, within various monitoring agents and so on. Today, I'm more inclined to think about what's wrong with a vendor organization that decides not to take that route. Rather than an innovation, I'd have to say such practice has now become standard itself, and a failure to comply has to be viewed with some concern.
--Ed--
Posted by Ed Tittel
Need some XML authoring/editing help? Get a little Oxygen
15 FEB 2006 21:26 EST (02:26, GMT)
Like many XML devotees, I count O'Reilly's XML.com among my favorite resources for inspiration, information and news in this ever-active area. Amongst the site's pundits and personalities, Kurt Cagle has always been near the top of my favorites list as well. That's why I read his recent story about the SyncRO Soft Ltd Oxygen XML editor there with great interest and attention.
I'm a long time user of Altova XMLSpy myself, but have flirted with Oxygen as releases have come and gone over the past three years. It looks like the time for more serious inspection may be at hand for me, and that you, gentle reader, might also benefit from a similar exercise as well -- at least if you're interested in checking out a state-of-the-art XML authoring toolset. I use the term "toolset" rather than editor or authoring tool simply because of the wealth of capabilities that Oxygen brings to its users: the product not only includes basic XML editing chops, it also works as an XML schema editor, an XSL/XSLT editor, does XSL/XSLT refactoring and provides XSL, XSLT and XQuery debugging facilities as well. It also works with all the big validation engines from Xerces to MSXML.NET to Saxon SA, and can handle SGML DTDs and Relax NG metadata as well as XML schema. It even supports batch operation for wholesale validation and transformation passes over document sets.
In fact, I could go on and on, but hopefully you get the point. This is a nice tool, and worth looking into if you're in the market for one. Licenses come in a variety of types and target different usage scenarios (professional/single-PC; professional/floating license; academic/home edition; and academic classroom). Costs range from $180 ($229 including one year of maintenance) for the professional/single-PC single-copy license to $48 for the academic/home edition, single copy license ($64 with one year of maintenance). The latter is, of course, a great way to try the product out before committing to a full-fledged commercial purchase, but there's also a free 30-day trial license available to those wiling to provide basic registration info at the company Web site.
Posted by Ed Tittel
Rules in a knife fight? Not exactly, but in an XML fight…
14 FEB 2006 16:35 EST (21:35, GMT)
Those old enough to remember the epic 1969 Western Butch Cassidy and the Sundance Kid will recognize that the opening phrase in this blog's title is lifted from a challenge to Butch's (played by Paul Newman) authority from an oversized member of the Hole in the Wall Gang. On the pretext of talking about rules for an immanent melee featuring sharp-edged instruments, Butch plants a foot in his opponent's groin and quickly ends things, proving conclusively that fighting about rules is as human and deeply rooted in our genes as fighting itself.
In the software world, creating rules also represents a major effort in codifying program logic and behavior and often extends beyond the boundaries of individual applications to embrace entire systems or looser federations of code that must interoperate and exchange data. This makes exchanging information about rules from one independent application to another pretty important, especially when such rules govern how one party might collect money or other valuable information on behalf of another party. That probably explains why the W3C has created a Rules Interchange Format Working Group to pick up the challenges inherent in creating a "…standard means for exchanging rules on the Web," where rules are defined as constituting "…a key element of the Semantic Web vision, allowing, integration, derivation, and transformation of data from multiple sources in a distributed, transparent, and scalable manner." Whew! Sounds like a pretty tall order, eh?
But according to Web pioneer Tim Berners-Lee of the W3C, this effort is intended to leverage years of industry and research into the composition and proper use of rules languages. XML can come to aid this effort through its powerful, regular syntax and abstract data representation capabilities, thereby "bringing together business rules vendors, user companies, rule language designers and Semantic Web developers to create a rules standard as an important step in achieving the full power of the Semantic Web."
All this of course, begs the question about what the Semantic Web might be. For this discussion, it suffices to say that where today's Web deals with the surface of language -- particularly in matching specific words or phrases with varying degrees of relevance -- the Semantic Web seeks to deal with the meanings inherent in language, so as to be better able to deliver what people really mean when they seek information and state their search requests, rather than concentrating entirely on the words they use to formulate such requests.
This should be an interesting project, and will deal directly with the need to make XML data relate to semantic structures, so that rules can "know" how to use the data that XML can deliver. In turn, this involves use of the resource description framework (RDF), the SPARQL query language and the OWL Web ontology language, to make sure that existing efforts to capture pieces and parts of rules (and by extension, a rules language) do not diverge from what this working group also takes up.
Personally, I can't wait to see how all this turns out, because it addresses some thorny issues in epistemology as well as software development. As the WG goes through its phases of development, it will be fascinating to see what kinds of tools and techniques emerge from their efforts. It may be years before it leads to anything we ordinary mortals can use, but it's certainly an epic attempt to grapple with important stuff. For more info see Robin Cover's news story on this subject and the W3C announcement.
Posted by Ed Tittel
The positive power of XML
13 FEB 2006 00:00 EST (05:00, GMT)
I started dealing with and writing professionally about HTML in 1992-1993, about two years after HTML left its cloister at CERN (Centre Europeen de Reserche Nucleaire, or European Center for Nuclear Research) in 1991. Even then, I understood that there were some things HTML was good at (managing and massaging text, with only clunky presentation power; hyperlinks, easy quick information delivery) and some things it couldn't handle very well (any kind of structured data, complex user interactions, dynamic information display, arbitrary data semantics and syntax). This began an ongoing adventure into dynamic HTML, JavaScript, Java and countless database tie-ins, document management systems and more.
Then in about 1997 I started hearing about XML, which immediately led to learning and exploration into this fascinating new metalanguage, which is fair to recast as both "SGML without the kitchen sink" and "a powerful open-ended data representation tool with simple, regular structure and syntax." For me, working with XML has been a continuing revelation: I've used it successfully to model all kinds of exam questions in building and refining online testing tools (the kind that deal with students, not systems or equipment, I hasten to add), to take advantage of enhanced content handling capabilities through XSLT and to explore great ways to exchange information for everything from security credentials to encryption and authentication methods, polls and surveys and their statistical analysis and all kinds of computer state and security information (patches and fixes, configuration data and more).
These days you can find thousands of well-defined, clearly specified XML-based applications for everything from software development, testing and QA, to mapping out various genomes (or building genealogies, if that's what you prefer). You can also take advantage of clearly-defined subsets of the HTML-inspired XHTML (through modularization techniques) to grab only basic sets of text handling and presentation markup for use on cell phones or other small-screen handheld devices, all the way to working with alternate character sets from Unicode for non-Roman alphabets and the languages that depend on them, to libraries of specialized notation for math, chemistry, physics or whatever other sets of characters your application might need.
I think it's fair to say that XML continues to enable all kinds of creative applications that would have been anywhere from difficult to impossible to build before it brought its powerful, flexible data representation and structuring abilities to bear on things we do for work, life, and leisure. I see this trend only expanding in years to come, and expect basic XML literacy to become as important to future generations as some basic knowledge of Greek and Latin were to scholars in the preceding millennium. Argue that point with me if you like, or ask your questions about XML, and I'll be happy to respond; e-mail me at or post to the Expert Answer Center.
Posted by Ed Tittel
|
|
 |
 |
 |
 |
 |
 |
MOST RECENT BLOG TOPIC ENTRIES
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
JUL 2008 |
|
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
|
 |
1 |
 |
2 |
 |
3 |
 |
4 |
 |
5 |
 |
 |
 |
6 |
 |
7 |
 |
8 |
 |
9 |
 |
10 |
 |
11 |
 |
12 |
 |
 |
 |
13 |
 |
14 |
 |
15 |
 |
16 |
 |
17 |
 |
18 |
 |
19 |
 |
 |
 |
20 |
 |
21 |
 |
22 |
 |
23 |
 |
24 |
 |
25 |
 |
26 |
 |
 |
 |
27 |
 |
28 |
 |
29 |
 |
30 |
 |
31 |
 |
|
 |
|
 |
 |
PREVIOUS ENTRIES
OTHER BLOG TOPICS
|
 |
 |
|