Project Cool Guide to XML for Web Designers - Softcover

Über die Autorin bzw. den Autor

TERESA A. MARTIN is the cofounder of Project Cool, the online resource for webmasters, and a celebrated interactive media guru.

Von der hinteren Coverseite

A complete webmaster′s and web designer′s guide to exploiting XML′s full capabilities for presenting data.

Project Cool(TM) Guide to XML for Web Designers.

Internationally renowned web developer Teresa A. Martin gets you up to speed on what XML is, how it works, how it fits in with other web design and development tools, and how, when, and why to incorporate it into your web site. Project Cool Guide to XML for Web Designers is the only XML guide geared specifically to the needs of webmasters and designers, and offers clear step–by–step guidance for integrating the XML process–from DTDs, parsing, and assigning style data to displaying a page in web browsers. You get all the background information and working examples you need to:
∗ Master the XML syntax to create well–formed and valid documents.
∗ Build a simple DTD and create elements and attributes lists.
∗ Attach styles to an XML document and display it in a web page.
∗ Work with XML and the 5.X browsers to display pages more powerfully.
∗ Use the new Document Object Model (DOM).
∗ Learn about the new XSL specification, CSS, and IE5 behaviors.

On the companion web site at www.projectcool.com/guide/xml you′ll find:
∗ A live demo that lets you see XML in action.
∗ Regular updates on emerging XML specifications and applications.
∗ Working examples of XML solutions.
∗ Visual glossaries.

Visit our web site at www.wiley.com/compbooks/

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

Introduction

Sometimes I think that everything is destined to go full circle. I got into the publishing business in 1979 because I needed to make money. I was a freshman in college, our campus paper needed people to typeset and I figured type, typeset, what's the difference, right? I could wing my way through it. In short order I ended up as a production co-ordinator, tucking the paper into bed at the printer across the river in the wee hours of the morning one night a week. This was a volunteer position. Somehow the hourly job had become, well, something else. I did, however, sometimes typeset things, enter the command to print, and process the film. Actually, it was RC paper. We stuck thumbtacks in one end and pinned it to the wall to dry.

This touching of the machine came in handy the following summer when I needed a paying summer job. I stretched the truth a little to a local type shop that was advertising for a temporary typesetter. I mean, I had produced typeset copy. In the following whirlwind month I proved that I could dance really fast, staying exactly one half-step ahead in learning what I needed to know to do the job. It was the fastest crash course in point size, leading, line length, kerning and typesetting coding you've ever seen.

The following fall I found myself addicted to those volunteer nights - there's nothing like standing on the BU Bridge, the link between the newspaper's office on the Boston University campus and the printer's plant across the river in Cambridge, just as the sun rises. You gaze down at the slowly-brightening Charles River as a lone car rolls up the usually bumper-to-bumper Commonwealth Ave., and know that your night's work is currently rolling off the press and maybe in a few hours the driver of that car will be reading a copy with his morning coffee. It made the publishing process visceral, human, and very real world.

I also found myself working at a weekly paper, as a part-time typesetter. I didn't quite expect the ancient blind keyboard (made by a company called AKI) and paper tape, but I learned how to splice, how to translate eight rows of dots into a letter, and how to code yet another typesetting system. I also became very good at handling large glass type disks with great care ... we were threatened that if the owner of the shop found a scratch, he'd dock our pay. Does anyone still remember those glass disks? Weighed what felt like a ton and went into machines made by a long-defunct company named Photon. Designers did not touch these machines. Type purists sneered that the output wasn't what it used to be.

A few years later I was still working part-time at this local weekly. I had graduated to setting ads, town warrants, and even boldly specing incoming jobs myself. Then we got this new system, from a company called Compugraphic. The system had the catchy name of Modular Composition System, or MCS for short. Suddenly we could see our code on a screen. And with a special separate preview monitor we could see how the text would look -more or less - when it rolled out of the processor. And, even more incredibly, we could typeset borders and rules! Instead of sticky border tape, we could pasteup one unit. The typesetters were suddenly designing ads, not just following a designer's

marked-up hard copy. We had the power.

I didn't realize it then, but it was the beginning of a convergence of formerly distinct tasks. These tasks continued to meld together, until along came desktop publishing and suddenly everyone should be able to do everything. It sort of matched the 1980s credo of super-achiever. You can do it all, you can have it all.

A decade later the Web made its appearance. The single part of the process that the one-man band of the desktop couldn't do was print many copies quickly and distribute them. We still needed some sort of press and post-press process. But with the web-Boom! Down went that barrier too. In those early, heady days of web publishing it seemed that all the walls were stripped away, the barriers had fallen, anyone and everyone could publish anything.

But publishing is a collaborative process at heart and as the web grows more pervasive as a publishing medium, it seems we are asking it to do more and more. And that's where the cycle toward one-person-do-it-all is beginning to turn back on itself.

You see, as we moved to the one-person/one-stop model we were also losing capabilities along the way. Part of what enabled everyone to do it all was good tools. But the other part was simplification of the tasks. With the old CG MCS and PowerPage, or the old Q5000 systems we could do some pretty amazing things. We could create what were essentially programmatic routines that would test for conditions and apply certain styles based on the value in counters and variables. (Of course no one would even suggest that we were programming - that required special knowledge of computers and we were just setting type.) We could batch process a 350-page book with varying headers and footers and even different styles chapter to chapter. We could make UDKs, user defined keys, that let us perform a string of common functions - text and code - with one keystroke. Those UDK values could include variables, so we could push a key and automatically enter the first part of a string, type the name of, say, the book in the book list we were building, and push another key and watch the string of commands finish entering automatically.

Oh, and on the post-press end our counterparts could selectively bind different sets of pages based on values in a database and deliver quasi-custom packages to different individuals. RR Donnelley invented a process called Selectronics which could be used, among other things, to deliver targeted advertising. In one well-publicized example Buick ran several different ads in the same ad slot in a magazine. The ad that appeared in any given issue would be the one that best matched the demographics of the subscriber to which the issue was going.

Was the subscriber in a suburban family zipcode? Ah. their magazine would be bound with the family vehicle ad. For a price, you could even ink jet print the name, address, and phone of the nearest dealer in the ad. But it wasn't just for ads. A magazine about parenting could target editorial and ads based on information it had about the age of the reader's child or children. A different cover could be delivered to urban and rural areas, or to eastern and western regions.

In those pre-web, pre-desktop publishing days no one person was expected to know it all and do it all. It just wasn't possible. We demanded a lot from the process and it took many skill sets to meet those demands.

I can't do it all!

Say this now, aloud, with me:

I can't do it all. I can't do it all.

This is important to remember as we begin, again, to add complexity to the information publishing process. With JavaScript, DHTML, CSS, and now XML and its stylistic cousin XLS, we're adding tremendous power and exciting new functionality. And we're creating a process that requires many different skill sets.

There's a lot of hype around XML. There are a lot of anxious web designers and developers who fervently believe they need to know how to "use" XML. But XML isn't one set of tags that you memorize, pop into a document, and voila! XML is now in your list of skills.

XML is a way of working with information in a structured form. Yes, there is a technical specification and some syntax that you can memorize, but syntax alone won't let you actually do anything. XML applications work at several different levels and unless you're a programmer or really want to be a programmer you're likely to be working with XML at a display level rather than deploying it within a database or generating the underlying complex tree structures.