"It would have been really smart to review this stuff with the community before releasing their software."--Dave Winer
I switched to Mac OS X two PowerBooks ago and haven't looked back. Steve Jobs-era Apple has a consistent record of shipping beautiful pieces of both hardware and software. Increasingly, Apple is exerting broad influence outside of the company itself. This week's column examines some recent Apple developments, to observe community reaction and draw some connections between various announcements.
Canvas, Painting Without a
David Allen has spoken about the need for structure and constraint to guide creativity, saying, "Try to paint without a canvas." Indeed, the <canvas> element is remarkably useful. Looking at something like the smoothly scrolling, zooming BART map widget in the OS X Tiger Dashboard makes me marvel. Why didn't somebody think of this sooner?
Well, actually, this really similar technology called SVG has been around for a number of years. So a better way to rephrase the question is either Why didn't the SVG group already do something like this so it could be reused? or perhaps Why didn't the canvas cohorts (including Apple) make the extra effort to build on the existing foundation?
Further complicating things, the implementation that shipped with OS X Tiger doesn't need or use an end tag, much like the old <img> element. The version tentatively specified by the Web Hypertext Working Group, however, requires an end tag for sensible fallback behavior. The Mozilla developer wiki already is collecting some material on techniques fitting in fallback content, and then masking the fallback content from Safari, and then performing further workarounds to prevent the previous set of workarounds from interfering with other browsers, notably IE. Normally, legacy issues like this take years over multiple revisions to unfurl, but canvas has done so even before a single final-grade specification is ready.
One way or another, canvas is an idea the world needs and awaits. But the process to get there isn't doing anyone any favors. The result could have been much better with a modest amount of additional coordination and outreach. Do more recent examples show improvement?
Podcasting: Acting More Quickly
Andy Grove said, "Leaders have to act more quickly today. The pressure comes much faster." Apple quickly jumped on a fresh trend as it released iTunes 4.9, which includes podcasting support and a directory via the iTunes Music Store. Getting added to the list is reasonably straightforward, based on a specification (strangely, available only in a PDF format with a microscopic font size); the basic process involves posting an RSS 2.0 file with a few extensions. Commentary quickly got down to specifics. Former XML.com editor Edd Dumbill wrote about some of the design decisions.
- The namespace used
http://www.itunes.com/DTDs/Podcast-1.0.dtd, which doesn't actually resolve to a DTD but still mixes a specific DTD version with a namespace--something that's caused pain in other situations.
- Duplicated metadata; for example, both Dublin
itunes:categoryelement, which, aside from similarities with RSS 2.0's element of the same local name, uses text in attributes and limits to two levels of categorization.
Edd wraps up the post saying, "What could have been a useful and reusable addition to the world of RSS is really rendered only fit for the single use of adding content into Apple's own iTunes store." There's more. Head over to Edd's blog for a full read.
Sam Ruby, with help from Mark Pilgrim (former "Dive into XML" XML.com columnist), also weighed in in the comments section, starting out by noticing discrepancies in the Apple documentation between the specification and the full-page example that comes with it. A few days later, another post zeroed in on some specific problems with case insensitivity, in violation of the XML Namespaces specification. A major, popular feed in fact relies on the erroneous behavior.
Apple has effectively redefined the entire structure of an RSS feed, added multiple core RSS elements, made all RSS elements case-insensitive, made XML namespaces case-insensitive, created a new date format, made several previously required attributes optional, and created a morass of undocumented and poorly-documented extensions...to what was already a pretty messy format to begin with.
The supreme irony of all this is that I remember Dave Hyatt (Apple Safari developer) bitching and moaning about all the work he had to do to make Safari emulate the buggy, undocumented behavior of Internet Explorer, and how the world would be so much better if only everything used XML and everyone implemented draconian error handling...
Sam goes so far as to call for links to draw attention to these issues: "I don't normally beg for links. ... All that being said, I want to increase the chances that the following information finds its way into Apple." Point taken.
In a related entry, Adrian Sutton points out that Apple ADC members have a specific channel with which to report issues to Apple. If all the coverage so far hasn't got its attention, perhaps some bug reports might. Reportedly, large numbers of duplicate issues are used to gauge severity of issues.
Tension: We Must Pull Together or Assuredly We Shall Pull Apart
Apple is teeming with brilliant designers, but the organization is also famous for being very secretive. It's easy to see a great deal of tension between keeping secrets and fitting into an increasingly open world. From Edd's blog again: "From a professional point of view, I'd say this looks rather embarrassing: Apple clearly don't have enough people who really understand XML."
I think understanding XML isn't the key issue--Apple surely understands XML and is cleverly applying it in ways that provide plenty of short-term kick for Apple itself. But designing for web scale is different than designing from a company-centric scale. For one thing, it's not enough for an internal group to work on a design. It's not enough for a small group, say registered Apple developers or members of a particular mailing list, to review designs. Others need to be involved, going as far as actively reaching out toward those working on something similar or those who might be affected in other ways. A side effect of such a pattern of behavior is that XML decisions that fall short of best-practice status tend to quickly come to light.
Within Apple are many examples of great community interaction: the open source Darwin core, blogging efforts pioneered by the remarkable Dave Hyatt (now joined by others), and the open sourcing of WebKit and WebCore underlying the Safari browser. Apple deserves applause for all it's done so far, and encouragement to keep making all the little course corrections needed to stay on track.
Births, Deaths, and Marriages
At least 11 xml-dev regulars are slated to speak at Extreme Markup 2005, August 1-5 in Montreal.
A $199 conference "helping demystify the world of XML" is coming up; a few xml-dev regulars will speak here too. July 28-30 in Raleigh, North Carolina.
Documents and Data
SVG code landing in WebCore?
Leftover from the last column: The XForms Wiki.