O'Reilly Digital Media

Real just released Harmony for iPods as well as number of other devices:

“With Harmony Technology, RealPlayer Music Store supports more than 70 secure portable media devices, including all 4 generations of the iPod and iPod mini, 14 products from Creative, 14 from Rio, 7 from RCA, 9 from palmOne, 18 from iRiver, and products from Dell, Gateway, and Samsung. Generally speaking, Harmony supports any device that uses the Apple FairPlay DRM, The Microsoft Windows Media Audio DRM, or the RealNetworks Helix DRM, giving RealPlayer Music Store support for more secure devices than any other music store on the Internet.”

Since Harmony is only depending on the iPod not to let the music move OFF the iPod, no reason they can’t use one DRM scheme (Real’s Helix DRM) to get the data to the real media player on the computer, and another scheme (Fairplay) to say “here, iPod, is an AAC file with fairplay. Play it but don’t let it be copied”. If the audio is in AAC at 192kbps to begin with (in the Real download service) there’s no transcoding of codecs or loss of quality. It’s really just the wrapper that is being changed, and the rules of how to use the audio.

It’s quite interesting. Apple has been a strong advocate of standards (AAC is a part of the MPEG-4 audio standard) but Fairplay has until now been a proprietary DRM standard.

The MPEG group (and a number of other groups) have been until now completely inneffective in creating the “one and only DRM standard”, and DRM is a notoriously hard problem especially when you try to implement it in software, which is always hackable without hardware support.
Real is pursuing what I consider a very legitimate and (they hope) effective approach in standards game; they approach the 3 major different DRM systems as defacto DRM standards and simply convert their tracks to the appropriate DRM standard, preserving the licensing limitations put on the media files they distribute, using the local DRM language of the device.

Although they reverse engineered the DRM’s on the players and did not directly license the DRM schemes, this is exactly where reverse engineering is often considered legitimate.

Apple may be able to beat it back. Real is not payingFairplay licensing fees. Although trans-drm’ing into Fairplay from real’s system can’t be considered a licensing violation (since it was reverse engineered), if any portion of the Fairplay is patented, then Apple will be able to use patent strategies (similar to how Microsoft defended the ASF format.)

There is a legitimate concern that a hybridized DRM system implemented through hacks and reverse engineering by warring business factions is potentially insecure. However, software DRM is always insecure (theoretically infeasible to implement a secure one), which is why Real was able to reverse engineer it to begin with.

In a pure business sense, Apple is (rightfully) concerned about having the iTunes-iTMS-iPod relationship broken. Many if not all PC users might use software that was more “PC” like harmony.

—-

I’m personally torn on this issue.

WHY APPLE SHOULD GET IT’S WAY:
I want Apple to win because I think they have the best political clout with the music industry and they were the first to break the market open with the labels while providing reasonable fair use permissions for consumers. If music industry trust in Fairplay, DRM, and Apple’s ability to defend it’s turf is eroded, the labels may get weirder again and generally start increasing restrictions on downloaded music.

WHY REAL SHOULD GET IT’S WAY:
I had always predicted that like any industry, several major proprietary DRM systems would come togther, be proved in industry, and then shake down to either a single agreed upon standard or a couple of leading but interoperable standards. This is a major step in that evolution, and the outcome of this skirmish has a lot to do with the eventual outcome of a bigger battle in the video DRM space.

And selfishly, I might finally get some Beatles tunes on my iPod if they come out on Harmony.

Please tell me what you think.

Related link: http://www.openpublish.com.au/

Open Publish 2004 here in Sydney just closed. (It grew out of the old SGML Open conferences, then became XML Open when the XML brand became hot, and then split out when the publishing industry attendees weren’t getting enough value from all the DBMS interest, and Nick Carr felt that there was a lot of synergy between the Open Source and Standards movements and the XML/PDF publishing industry.)

The quality is not so much in terms of papers or size (though these are good: Oracle’s Ben Chang, open content mangagement’s Michael Wechner, Tim Arnold-Moore, PlanetPDF, Microsoft, Adobe), but in terms of networking: for many people, it is being able to chat to old/future collegues, competitors, fellow travellors and potential consultants/clients that is just as important as the papers. A large conference covering to too broad an area means, in effect, that there is only a small chance that someone you talk over coffee to is interesting to you.

At this conference, just casually talking to people, I discovered a large publishing company who used Schematron with a checkbox interface, so that people could turn on and off the assertions they were interested in. That is a great idea. My implementations of Schematron (the open sources ones at Academia Sinica, and the commercial ones from Topologi) all support phases (a higher bundling of assertions) but not individual assertions in each rule: it seems like a really nice capability and the checkbox interface is obvious.

If I were to pick a theme or meme, it was that the decision on whether and how to support Word was the by far the most critical decision for most large XML deployments. Deciding not to frees you up considerably, but some users are pathetically entrenched, if you can forgive my sympathy for lapsing. If you decide to use it, then you need to spend a lot of resources on figuring out how to do the conversion (lots of tools now) and, more imporantly, how to force authors to only do things that will make it into the XML.

(Talking to someone else who was forced to accept RTF, I mentioned my old trick, which saved many projects: you get the Word users to first save as RTF, then to relead the document and save again. This does two things: first it tidies up the eventual RTF, second it exposes if anything essential is not round-trippable through RTF—this may be more comforting than important, though.)

David Drinkwater’s paper analysing the twists and benefits of a beefy yearlong project involving scores of CD-ROMs and books, in the area of moving adult learning objects published in paper/CD/Web formats to a single source. He said he doubts it is possible, for most kinds of material, to entirely use single source; when people tried to do too much formatting, the XML approach failed; the benefit was in not needing to hire an HTML designer for each CD, because the same design was reused. He said the project was supposed to take 6 months, but blew out to 12 months (how typical): I asked him how much time was spent on dealing with Word, and he said 7 months (they serialized out the internal DOM of Word rather than convert to RTF, and they didn’t want to upgrade to Word 2003 with the nicer XML export.)

I couldn’t help wondering to myself whether that 7 months was the cause of the 6 month blowout; David did say the Word handling took more resources than each of conversion to CD, PDF/paper, or Web. I didn’t say anything, out of politeness to the other speaker (a cheerful Microsoft guy with a good Infopath demo: XForms really is its competitor) because I was chairing. I managed to introduce David as Michael, embarrassingly.

I enjoyed Dr Peter Sefton’s paper most; I "http://www.oreillynet.com/pub/wlg/5336">blogged
it earlier.

James Robertson’s presentation on Content Management Systems (CMS) was very stimulating too. He said it seems that you should limit your CMS implementation plans around “What will my needs be in 2 years time?”; any contract or expectation of putting in a CMS that will need an ROI or value longer than this is foolish. I chaired that session too, and I always like to ask a question that “forces” the speaker to state more bluntly what they may be too politic to say: so I asked James whether he had ever seen a CMS project intended to meet needs longer than 2 years succeed: he said he never had. A big upfront budget on an expensive product may mean less ongoing funding to customize and take advantage of the swanky features. Many of James’ other point centred around the same core idea: I would restate it as projects targetted at the long-term fail in the short-term, are abandoned in the mid-term and never make the long-term.

Corridor gossip that the military may here are seriously looking at adopting "http://www.s1000d.org/">S-1000D
International Specification for Technical Publications
utilising a Common Source DataBase
for new projects. Our existing 5629A DTDs were a compromise to codify the existing practise in different services. Actually, this was another meme in the conference: that often it is better to first implement something that modernizes and regularizes the production process, without being to purist, and then, when the processes and technologies and expertise is in place, move up to a simpler, unified, company-wide schema. The initial move should concentrate on things like faster delivery time, or cost-cutting and process re-engineering; it remined me of a recent project I worked on where they discovered they could not put in a CMS until they had cleaned up their documents, which would take two years.

While on that topic, yesterday I heard of one organization that discovered it would take 3 days per document to collate a definitive version of their technical manuals (which had years of loose-leaf updates): that being so, their plans to convert the most critical 500 (of their thousands of) documents into a CMS would take about 70 man years: and they only had a 10 man team. And that is before conversion, checking, etc.

I had been asked to give an updated version of my
>Wiki-to-XML article at XML.COM. It was well-attended, and I was surpised when the local Boeing people said they were using a kind of Wiki internally for collaborative writing. People who use it, often love it. I guess we must never believe propaganda that says users require WYWIWYG authoring, especially when issues of convenience and efficiency dominate.

In my presentation, I showed a 400 character little document. To mark it up in XHTML took about an extra 430 characters. To mark it up equivalently in a Wiki took 9 characters! Hmm, 430 against 9: is terseness really of "http://www.w3.org/TR/REC-xml/#sec-origin-goals">minimal importance even when using cheap fingers?

To mark the same text up in HTML using a customized HTML editor took between 15 and 27 mouse actions (depending on whether you did it all at once or separately from data entry.) My point was to suggest that a 50% reduction in keystrokes (well, given that any decent XML editor will provide templates, end-tag generation and other features, this is problably more like a 30% reduction) is nothing to be dismissed automatically, and that is just when you are adding data+markup: if you are marking up existing raw text, the Wiki is between 4 to 20 times less work! Of course, to make use of it, you need to forgo attributes and (probably) deeply nested element-content elements. But you can always stick on an XSLT transform at the last stage and convert to your production schema.

This show I was also wearing my spruiker hat as an exhibitor: Topologi’s new Professional Edition 2.1 is being released Monday, adding a lot of analytics and reporting capabilities to the existing validation and making everything work with everything (we can validate SGML with Schematron now!); I’ll sneak the Wiki-to-XML converter into the distribution as a freebie. My appointment book is pretty full next week for people talking about buying; so all in all a good, targetted conference for me.

Should you scream if the O’Reilly Network has one more blog from a conference this week?

Related link: http://ptsefton.com/blog/

Really good analogy from Dr Peter Sefton, at a presentation in this week’s Open Publish conference in Sydney. I enjoyed his presentation more than anyone others I saw, not the least because his laptop died minutes before starting, so he had to give the whole thing with a paper pad and acting out the photos. The presentation is now at Peter’s
blog.

His point, basically, is that when you are cycling, a steep hill is bad, but then when you coast down hill after, things are easy. But if the hill is too steep, you go around and don’ t make the climb at all.

Similarly, with XML conversion projects, if you decide to convert to be suitable for all possible multi-source conversion projects in the future, intended or not, you are setting yourself (and your markup people) such a hard task that it may be too much effort. Even though you know that you will be coasting afterwards.

I think Peter is suggesting that conversion projects should be staggered: do enough to meet your short-term requirements, and incrementally add value to the data as it is required. Maybe this is a variant of href="http://c2.com/cgi/wiki?YouArentGonnaNeedIt">YAGNI?

Are you going to need it?

Related link: http://xmlopen.org/programme.html

The program for the "http://xmlopen.org/programme.html">XMLOpen 2004 conference is now out. A great line up of speakers,
including Uche Ogbuji (Python guy, a frequent writer
for OReilly, IBM, and trade papers, and definitely "http://www.oreillynet.com/pub/au/1054">photogenic), Dave Pawson,
Murata Makoto, Eric van der Vlist, Michael Kay, Sebastian Rahtz, Martin Bryan, and more.
Keynotes from Jenni Tennison, Sean McGrath and
me!

The conference is oriented around practical experiences with standards and open source systems, it seems; their conference "http://xmlopen.org/aims.html">aims seems quite unique: they promote the conference as an opportunity to come and talk over tools, techniques, problems, solutions with a pool of peers and experts during the conference. This seems much more valuable than the traditional “Shut up and listen” approach of some conferences.

Thinking about the conference, I am coming over all shy. When I arrived back in Australia from 3 years in Taiwan, I hunted out some nice Italian bread and, unguardedly, broke my tooth on its hard crust. I wonder if I should get that tooth capped, to be less disreputable looking for the audience; on the other hand, English people seem to quite enjoy interesting teeth. Perhaps Dick Emery vicar-style false teeth might be better…oooh why did I ever get involved if I am losing my nerve already! In Taiwan, I did some male modeling, believe it or not, for a mobile phone company: "http://www.sinica.edu.tw/~ricko/rick2.jpg">me mug was on the side of buses for weeks, so it is odd to be getting nervous about appearing in public. (It turned out that I was the closest thing they could find to an 80 year-old Western bald guy with a hole in his skull revealing circuitry, I found out just as I was congratulating the mirror on defeating time.) Normally I don’t care who thinks I am idiot: but should I really have signed up to provide more evidence? Anyway, it sounds like a fun (err, I mean, useful) conference.

More to come….I will blog a report on this week’s Open Publish 2004 Conference in Sydney later tonight. Lots of interest for XML and publishing people.

Why is Sean McGrath’s photo on the website, when they could have Rick’s?

My favorite OSCON presentation on wednesday was Brad Fitzpatrick’s “Inside LiveJournal’s Backend” presentation. This year at OSCON there are a number of presentations that focus on high availability, scalability and growing web sites, and Brad’s presentation was the most down to earth presentation. When comparing the story of LiveJournal to the story of TicketMaster, it’s clear that LiveJournal has more of the open source bootstrapping feel to it. The TicketMaster presentation shows that TicketMaster started off with a huge budget to buy all the right hardware, whereas LiveJournal started by randomly cobbling together hardware from random sources here and there.

LiveJournal started in 1999 with a shared server, which was promptly killed with too much traffic. The first dedicated server didn’t fare much better, and from there Brad started collecting money from users to afford the hardware to host the service. Today LiveJournal is a colorful collection of 90+ machines that employ a lot of fail over techniques and custom sofware bits that complement the off-the-shelf open source software that powers the rest of LiveJournal.

Rather than going into all of the details of Brad’s talk — go check out the PDF of his slides — there is a lot of valuable information in there. If you find yourself hosting a web sites that is starting to push the boundaries of your current hardware, go read the slides.

The scary thing to me is that MusicBrainz is currently in step 2 of the LiveJournal history. We have two servers which are starting to strain under the load — we’re planning on adding more servers soon, but will we end up operating 90+ server 5 years from now? Egads — I hope not.

Regardless of where MusicBrainz is going in the future, I feel less dread about scaling our service than I used to. It seems that the open source community has started working on high availability and scaling tools (e.g. memcached, wackamole) that will make scaling web sites easier and cheaper. Not requiring expensive specialized hardware and relying to software solutions running on commodity hardware makes a lot of sense to me.

While taking in all this valuable information about creating scalable web systems, it becomes clear to me that the organization of a scalable web site heavily depends on the data being used in the site and what users are doing with it. No doubt the LiveJournal and TicketMaster models would not work for MusicBrainz. I guess its time to put on the thinking cap and start planning how MusicBrainz might be scaled up in the future.

What other open source tools do you use in managing a large web site?

New consumer electronics devices leapfrog their predecessors by incorporating new types of functionality that re-define the “problem” their predecessors solved. Just think, for example, how TiVo has re-defined the VCR experience. Well, if the embrace and extend strategy can work for the innovator, then such a strategy can work for the predecessor. Along those lines, I have been ruminating on the question of what would the cordless telephone look like if it were to be re-invented?



A few worthwhile innovations stand out, none of which have been incorporated into any of the cordless phones that I have come across. First off, is a unified phone book within the handset itself. We take it for granted that within our cell phones are many tens, if not hundreds or thousands of phone numbers which are relatively easy to input into the phone, and can be called up in very few click strokes. Why then is the cordless phone still very much in the dark ages in this area? Seven times out of ten when I want to make a call at home I end up defaulting to using my cell phone as my home phone replacement since I have the number I want to call in my cell phone, don’t use paper phone books and can’t remember every phone number (e.g., a favorite restaurant to order to-go food). Needless to say, it is a major inconvenience to have to run and grab the yellow pages, and painful indignation to have pay $1.25 for directory assistance when the convenience could be right at my fingertips. The above scenario should scare the bejeezus out of the “Baby Bells” because it is but one example of how a former monopoly goes the way of the do-do bird. Similarly nice, but non-integral, would be if this function could wirelessly integrate with my Contacts in MS Outlook (or whatever favorite information management software you use).



Secondly, if my cordless phone could piggyback on top of my Wi-fi connection then I might be able to “connection-switch” between POTS (i.e., plain old telephone service) and VOIP (i.e., voice over IP). Why is this a good thing and why should the new cordless telephone have such capabilities baked in? Basically, it would enable me to turn my ordinary telephone into an Internet-powered walkie-talkie service (hence, “tawkey”) so that minimally I could talk toll-free with friends and loved ones that have a tawkey-enabled phone (this scheme worked pretty well for Nextel in creating a self-reinforcing network effect), but optimally, I could leverage one of the emerging VOIP service providers without putting myself into the all-on-none quandary of choosing between VOIP (cheap to free, generally replaces POTS connection) and POTS (not so cheap, but very reliable, especially in case of power outages and emergencies). Different flavors of the phone might support more advanced communication features like instant messaging and email retrieval, co-opting some of the popularity of Blackberry types of devices.



To be clear, connection switching could actually provide two features in one. On one level, this functionality would enable switching between POTS, VOIP and ultimately, the third-mode in unified home telephony, cellular (I am dreaming, but we are clearly not far away, as a recent article on an href="http://my.netscape.com/corewidgets/news/story.psp?cat=50380&id=2004072607490002966682">HP/T-Mobile announcement addresses). Initially, this functionality would be manual in the sense that you would have to click a button to choose the preferred connection type before making the call. Ultimately, the technology would evolve to automatically switch to the cheapest, most reliable path (or default paths for specific types of calls — think cheap when calling cousins in Peru). On another level, such a phone (or its base station) might deal more elegantly with spectrum contention when both the cordless phone is in use and Wi-fi traffic is taking place. This alone might be a reason for many to replace their old cordless phone.



So who is the customer for such a product, which I call Tawkey Tri-Mode (tri-mode = POTS/VOIP/PCS)? It’s the home cordless phone replacement market, a fairly sleepy segment, which nonetheless moves over 30 million units, and generates $1.6B in revenues a year. Moreover, it’s the 50 million or so people with Wi-fi connections who see home broadband as a logical convergence point for next generation telephony applications. And it’s the 17 million people that have had an “aha” moment using Skype on their PC and who would like to extend that moment to their living room and kitchen. Ultimately, it’s the 1 billion cellular users and purchasers of 500 million handsets annually who would like to marry the convenience and flexibility of cellular (and their cellular handset) to the reliability and (relative) cost-effectiveness of POTS when at home.



One key takeaway in all of this is that to deliver the goods, the offering needs to incorporate a new cordless phone and base station design, a network service to route and link up other Tawkey users, and potentially, a synch server that lives on your PC and periodically syncs Tawkey data with that on other devices, like your PC, PDA, cell phone or another family member’s devices.



One comment about sync server types of functions. While one continuing trend in the industry is to collapse ever more features into a single device, my gut is that the device age will truly be upon us when I instead have one master data store, and multiple, simpler and/or more specialized devices sync’ing with it. For example, I should have only one master phone book, but I probably don’t want all of my work numbers on my home cordless. Same deal with digital content. (But that’s a blog for another time).



So who drives this innovation? Is it the cordless phone makers, like Uniden, V-Tech or Panasonic, who have no sacred cows to protect in terms of service provider relationships? Is it the Nokias and Motorolas of the world working in tandem with cellular service providers, who could aggressively target the home phone replacement market with a hybrid PCS/VOIP solution? Perhaps it’s the baby bells needing “something” to reinvigorate themselves and gain better leverage to up-sell and lock-in their current customer base with a hybrid POTS/Internet/VOIP offering. For that matter, why not Sony, who truly gets digital convergence, or even Apple, who has proven time and again, their ability to re-invent markets?


There sure are plenty of different ways to make money on this. Sell handsets. Build intellectual property and license it for passive royalty income. Cut revenue sharing deals with DSL, VOIP or cellular access service providers. Or, pursue a premium revenue strategy by offering in-network or Tawkey-to-PC push to talk for free, and managed VOIP (similar to services like Vonage) for a monthly fee. Similarly, one could leverage this model to build an IP-based enhanced 411 directory service (think: gives option to automatically add number to phone book and coupon option on enhanced listings).



To be clear, there are some potential chicken and eggs. For one thing, hardware is expensive to fund and manufacture, and channels to distribute new products are notoriously difficult to secure. Plus, consumers are slow to embrace new ideas, as TiVo has discovered, taking almost seven years to secure 1.6M subscribers. And service providers are known laggards in terms of embracing new market opportunities. Further, there are issues of how reliable Wi-fi is for voice connectively in a typical home roaming environment where you are walking from room to room, and security is always a concern both from a secure tunnel and data accessibility perspective (e.g., I would not want there to be any meaningful risk of a “neighbor” with a Wi-fi scanner hacking their way into my cordless phone’s phone book).



At the same time, the idea has some promising bells and whistles. One is that it sits at the convergence point for multiple large markets, and there are multiple players with a vested interest in not missing the boat on the opportunity — think: baby bells, DSL, cellular providers and handset makers. Plus, walkie-talkie functionality has proven itself to be the first “killer app” of 3G, and the application by definition reconciles the battery life and bandwidth issues that stand in the way of broadband-optimized communication applications by piggy-backing on the price-performance wave of Wi-fi, DSL/Cable, and close proximity to its base station for easy battery re-charge.

Is Tawkey compelling? Would you use it? Any fatal gotchas?

I’ve never quite listened to such a presentation before. Ever! Educational, yet hilarious. Ludicrous, yet, erm… useful?

I’m not sure this will make sense — listening to Damian give this presentation made me laugh so hard that I was convinced it was all nonsense. But in the end it was not — I’ll try and convey the basic gist of his talk.

Damian started out talking about the game of life — the cute simulation that shows complex behaviour arising from simple rules that has fascinated us all at some point. He wrote a DFA (discrete finite automaton) class for perl that he used to show us the game of life. He then began changing the rules of the game and eventually showed us how to build a NOT gate using the game of life. He then proceeded to outline how one could implement a Turning Machine in the game of life.

Crazy stuff, for sure. Damian then turned his attention to Klingon. Yes, the ficitious language that arose from Star Trek. He proceeded to map Klingon words, complete with the proper pronounciation and enunciation, to the perl language. Describing it won’t do it justice — you had to be there to experience it. I was laughing almost the entire time and at points I had to stop and try and gather my thoughts so I could still follow this madness — afterall Damian Conways always delivers in the end and I didn’t want to miss the punchline. Seriously, laughing and paying attention to seeming nonsense is hard work — especially late in the day.

After mapping Klingon to perl, he took a detour into the Second Law of Thermodynamics and James Clerk Maxwell’s “Maxwell’s Demon” thought experiment. Wikipedia explains this experiment as:

In 1871, the Scottish physicist James Clerk Maxwell proposed a thought experiment. A wall separates two compartments filled with gas. A little “demon” sits by a tiny trapdoor in the wall. It looks at oncoming gas molecules, and depending on their speeds it opens or closes the trapdoor. The object of the game is to eventually collect all the molecules faster than average on one side, and the slower ones on the other side.

We end up with a hot, high pressure gas on one side, and a cold, low pressure gas on the other. Conservation of energy is not violated, but we have managed to redistribute the random kinetic energy of the molecules (heat) in such a way that energy can now be extracted from the system (it can drive a gas turbine, say).

. . .

In Maxwell’s thought experiment, the demon manages to decrease the entropy, in other words it increases the amount of energy available by increasing its knowledge about the motion of all the molecules.

Got that? Good. Damian didn’t know what to make of it, so he decided to simulate the experiment. Now nearing the end of his talk, what else would he choose to simulate this experiment? The game of life, of course!

He proceeded to work up an appropriate simulation for Maxwell’s Demon, and the simulation held true (contrary to what Wikipedia says)!! The gas molecules did in fact collect on the hotter side. However, he pointed out that the flaw in the simulation was the number of particles in the system. By increasing the number of particles, the Demon can’t prevent hot molecules from escaping back to the cold side and thus the Second Law of Thermodynamics holds and Mr. Conway simulated that fact with the game of life.

But what about the Klingon? Well, it turns out that Damian wrote a Klingon module for perl, which allows programmers to write perl code in native klingon! And of course to wrap it all up, he showed us the code for the Maxwell’s Demon simulation written in Klingon.

Wow. I’m blown away. And now that the tutorials are done, we’re on to the conference portion of OSCON. I look forward to someone else blowing my mind in the next few days.

So, have you written any programs in Klingon recently?

I’m a big fan of perl — I’ve written lots of code in perl and I plan to write a bunch more this fall. But now that I am browsing the OSCON convention program, I am starting to worry about perl 6. For instance, the description of Allison Randal’s “The Perl 6 Compiler Today” presentation states:

While it’s true that it’ll still be a few years before we see a complete beta of Perl 6, there’s a good bit of code working now, if you’re not afraid to dance on the bleeding edge.

And Damian Conway’s “Perl6” presentation description says:

The design of Perl 6 has moved ahead significantly in the past twelve months. …

We’ve now seen several years of perl6 design and it looks like there will be a few more. Don’t get me wrong — lots of design is a good thing and the perl team is going about it very methodically. However, this process does seem to be taking a bit too much time.

I keep having to think about M$’s Longhorn OS. Its been pushed back time and time again and it won’t see the light of day until ‘06. In the meantime Apple has new OS releases much more frequently and it seems as though every day some Linux distribution has a new release. I think M$ is vulnerable in taking so long to bring Longhorn to market — vulnerable to smaller, more nimble players to come in and take away market share.

I’m worried that perl6 is exposing itself to the same kind of peril. Python has grabbed my attention in a big way and it seems that killer new scripting languages are coming around every day. Will the carefully crafted perl6 have a chance to maintain its position as the hacker’s scripting language of choice?

I’ve always preferred many smaller releases rather then infrequent large releases (release early, release often, right?) and large releases set of warning bells in my mind. Is the technology becoming too heavy? Longhorn certainly is, but is perl6? Will perl6 be worth the wait?

It wasn’t my plan to focus on perl this conference, but now my curiosity has been piqued — I’ll poke my head into the perl6 sessions and see what I think after the conference.

Are you worried about perl6?

Related link: http://www.xml.com/pub/a/2004/07/21/dive.html

Mark Pilgrim is usually excellent, so I was perplexed to read his latest XML.COM article “XML on the Web has failed” in which he uncovers the horrible fact that XML is unreliable when used unreliably. Knock me down with a feather!
Mr Pilgrim could correct his article by substituting text/xml for xml in most places, and by removing the snide-seeming opening and closing comments.

To set the scene, here are some quotes from the IETF discussions on RFC 3032, five years ago:

• Most XML objects have no business being registered under text… (There is a )
  lack of ability to dispatch
  on parameters in most applications that support MIME.
  ( "http://www.imc.org/ietf-xml-mime/mail-archive/msg00006.html">
  Ned Freed)
• Users need application/xml rather than text/xml to ensure end-to-end integrity because the out-of-band approach
  has so far failed to provide that integrity…
  Out-of-band signalling of the encoding of a file to some extent a hack to
  cope with formats that are not adequately self-describing. I would have
  no problem with removing text/xml entirely
  ( >Rick Jelliffe)
• Fallbacks to text/plain are not useful in
  general, and fallbacks to 7-bit US-ASCII risk mangling the data.
  ( "http://www.imc.org/ietf-xml-mime/mail-archive/msg00048.html"
  >Chris Lilley)

Pilgrim’s argument is roughly:

• XML must be served as text/xml, and with the correct charset parameter in the MIME header to be well-formed
• But, oh no! From a large collection of RSS servers we see that about half is ASCII and the other half is wrongly labelled or not well-formed.
• Therefore all XML is broken, because XML promises you can “publish in any character encoding”.
• Doh, this was something that slipped by the developers of XML and the RFCs, and which we will know better next time.

All those are wrong:

• XML should not be be served as text/xml. In fact, RFC 3032 and RFC 3470 recommends against it (except for “casual” inspection purposes, not typical XML). Most recently, Sir Tim and the W3C Technical Achitecture Group’s latest draft guidelines make it very clear that application/* with no charset parameter should be used.
  Even the XML spec, which does not concern itself with transmission issues, recommends against it (for “files”.)
  When the data is a sequence of bytes, such as a file with no metadata or application/xml, you use the encoding declaration; when the file is a sequence of characters (such as a Java String or text/xml) the encoding declaration is irrelevant; programmers just need to be aware when they are dealing with bytes or characters.
• If I sampled a Japanese aggregator and then said Because none of the sources use ASCII, ASCII has failed! people would be surprised. Of course when Mark looks at a site will almost entirely US sources, he finds a very high incidence of ASCII data: this has absolutely nothing to do with the characteristics of XML. That 20% of RSS is badly tagged is hardly surprising, and no reflection on XML either. That the XML header and the MIME charset disagree may not actually be significant, simply because few systems use the charset parameter anyway because it has always been unreliable: HTML browsers, for example, use a mix of information such as locale-specific defaults, the most recent pages, and byte patterns to guess the encoding used. Often, systems will just read data in in the locale-default encoding, so people are often not aware that their plumbing is wrong. Unless things have changed recently, the de facto default encoding for text/* is the system’s locale-default encoding: in fact, MIME’s text/* is a red flag that data may be fiddled with.
• Putting aside the bogosity of making a conclusion about all XML from one application (RSS), XML simply has never promised that you can publish reliably in any arbitrary encoding. The quotation marks around “publish in any character encoding” may give some people the impression that this it must be an official goal of XML. Who is this quoting? I couldn’t find it on Google. XML processors are not required to support every encoding, and character references are not available in markup anyway. It seems a bit rich to fault XML for not satisfying a promise it never made.

My Life as a Dog

But some of the statements concern me directly. I first proposed the auto-detection algorithm that became XML’s Appendix F. My first jobs as a programmer involved writing automatic rate-detecting UARTs for microcontrollers, and I had years of experience figuring out what information can be detected from bit patterns, watching signal traces on protocol analysers and other gizmos. Work in East Asia gave me knowledge of other encodings. I think I solved a big problem well. I take great satisfaction whenever I read people attributing XML’s success in large part to its internationalization, because that is the part I influenced most (though I always hold that XML’s success is just as much due to the taste of the people who were good at filtering out bad ideas as to the lightbulbs from those of us who could contribute new ideas, if you catch my drift.)

Naturally it bothers me to be informed that we were not aware of some issues that, in fact, we were actively trying to solve. How dare someone not love and adore me!

So Pilgrim could not be more wrong than when he claims that these encoding problems somehow slipped us by. It was because we already knew then that out-of-band metadata was inadequate on several levels that XML adopted the in-band labelling solution. Mark’s mistake is in thinking that the charset parameter of a text/* content-type in the MIME header of resource retrieved using HTTP can, will or should work reliably.

There are five different approaches to character encoding:

• Ostrich-like: it is all too complicated, it doesn’t concern me, let the foreigners solve their own problems.
  Obviously, the W3C takes the ‘World’ in ‘World Wide Web’
  very seriously, so this approach is a non-starter.
• Puritan: let everyone adopt UTF-8 (or UTF-16) and ban everything else. This approach was favoured by many Unicode people, but has the disadvantage of being unworkable. Legacy data and locale-specific defaults are a fact to be dealt with, not a embarrassment. (However, XML allows the best aspect of this: it provides an on-ramp to Unicode.)
• Ungenerous: let everyone adopt ASCII. This is the approach underneath, for example, the painfully slow progress towards allowing non-ASCCI characters in domain names. I used to hear (even from Asians) the comment “Everyone should learn English” as the answer to encoding issues: this is little better. (Again, XML allows this to a good extent, allowing ASCII with character references.)
• Magical: waving a magic wand in an HTTP header. Some people seriously believe that the only use-case XML needs to concern itself with is as packets generated at an HTTP server and immediately used by an HTTP client. However, XML is often stored in files before and after transmission, and XML is used for configuration files. This introduces the real possibility of configuration error, because the person who creates a file may be different from the person who configures the webserver. Furthermore, typical file-reading and -writing APIs do not force the programmer to be aware of the encoding used: programmer ignorance is positively encouraged.
• Systematic: encoded data must be inseparable from encoding metadata. Given that most file systems (or APIs) do not support metadata, the only feasible way to do this is to provide in-band signalling of the metadata. Consequently, out-of-band signalling should be used only as a supplement.
  This is the route that XML took: its success in neutralizing the character encoding issue is clear; whereas ten years ago the hundreds of character encodings represented a swamp that prevented interoperability, nowadays encodings are regarded as local optimizations that are just another design trade-off. It has utterly changed the landscape.

Obviously, Pilgrim is a controversialist. But discovering that when you use XML in an unreliable way, XML is unreliable should be the source of no wonder. That out-of-band signalling of encoding (such as MIME’s text/*) has a particular set of problems is not new information that we poor, ignorant, simple-minded geeks didn’t know about in 1996, and which we have embarrassingly discovered since: it was our departure point then. That is why the encoding declaration exists!

The continued popularity of text/* for XML makes it important that XML processors fail when they find infeasible byte sequences; and this is the reason why XML 1.1 took a positive step to banning the C1 control characters from appearing literally. Some people think it is bad that this introduces a superficial syntactis incompatability with XML 1.0, but the advantage in error detection warrants it.

Finally, you can lead a horse to water, but you cannot make it drink. Use application/xml not text/xml. If you don’t know what the encoding your system uses and so you don’t know what encoding declaration to use, force it to UTF-8 and remove guesswork from the equation.

I’m off to summer camp O’Reilly’s Open Source Conference in Portland. I’m looking forward to showing my “What would Larry do?” shirt to Larry Wall, and to thank Guido van Rossum for writing Python — I’ve been enjoying Python (and making money with it!) for the last few months. Time to give credit where credit is due, and OSCON is the best place to do that.

I’m giving my Lazy Replication with Postgres Talk at 4:30 this Thursday — please come check it out if you tinker with Postgres. Other than that, I’ll be posting notes from the conference here, so stay tuned!

Are you going to Portland?

Many great open source GIS tools are available for data manipulation and mapping projects. Many of these, however, only have command line interfaces (CLI) available. As such, there are a lot of folks for whom these tools are virtually inaccessible.

Oddly enough, every time I look for the “command prompt” in one operating system’s START menu, I get the feeling it’s hidden deep in the menus for a reason. Could it possibly be that some users are discouraged to even use a CLI when so many wonderful graphical user interface (GUI) tools are available? Okay, forgive my sarcasm, but it seems that we prefer to scan the screen looking for “event” driven controls rather than read about a list of commands that we can type in.

At risk of entering into the larger GUI vs CLI wars, I wonder about what approach to take when introducing new users to these great tools: create a GUI or help them stretch.

I think it goes without saying that GUI-addicted users find command line interaction as exciting as elevator music. Not only does the CLI of their particular operating system appear unfamiliar to them, the fact that it “just sits there” waiting for them also introduces a sort of dependency on the user - you must know what you need to type or nothing will happen. Their verdict, as discriminating as it may be, is that CLI is archaic and hard to understand because it doesn’t pour forth speech in their mother (msgbox) tongue.

This is a whole area of advocacy that I haven’t seen addressed: how to make that leap between user interaction paradigms without coming across as “Mr. IhateMouseClicks”. I know that once they’ve seen the power of a few CLI sessions helping to solve their problems, they may be more interested in flexing some new muscles.

Of course, with Geographic Information System (GIS) applications comes the regular need for visualization and interaction, often through maps. So I can’t discount everything graphical - nor am I trying to. But I’ve found that in many cases, the tools we have at our disposal better fit the CLI paradigm. That is they have a “Command ” logic which is more succinct than the “Click here - browse for file - select from list - click OK” paradigm that many users are constrained to.

I’d like to hear how others have helped to bridge this gap, particularly between traditional Windows users and Unix-style applications. How do you bridge the gap between excellent command line interface-based tools and users who need them but who were raised on GUI bread? I’m interested in a female perspective too - maybe this problem is just a male thing (like not wanting to read the map when driving, preferring to just wander through the operating system waiting for buttons to appear).

I propose creating a non-profit society: CLI Advocacy. Its sole purpose would be to combat the “GUI is the only way league”. Or perhaps it should be “CLI Users Anonymous” - after all I feel I’m more in need of a good support group than being involved in a direct attack.

Tyler

How do you bridge the gap between excellent command line interface-based tools and users who need them but who were raised on GUI bread?

Related link: http://www.disinfo.com/site/displayarticle4565.html

A topic dear to my heart: open source television.

Related link: http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0000/…

That non-Microsoft browser makers have organized themselves
as the WHAT Working Group
to develop browsers further should come as no surprise: Microsoft is obviously looking in the direction of XAML and is probably quite happy with the current state of HTML.

The esteemable T.V.Raman makes several good points in the transcript of
the recent
"http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0000/2004jun01.html#topic13"
>W3C Workshop on Web Applications and Compound Documents,
especially
We have stagnated in the last 5 years.

Of course, every-one knows how HTML subsetted SGML syntax (and the ISO DTD, in part)) and how XML subsetted SGML syntax differently, and both have been very successful for different things. I don’t want to bore you with my views on why XHTML (when conceived as a replacement for HTML, rather than a different stroke for different folks) is dumb. I have other things to bore you with!

I have been working on two projects over the last several of years that have made me think the problem with HTML’s stagnation and XML’s lack of success on the client is not just to do with the HTML WG being forced to cope with XML, nor with the kitchen-skin standards. Nor even with the database/business focus at W3C nor Microsoft’s boredom with standards making.

I think the essential problem with browsers is that users have not demanded of vendors (which is a polite way of saying that vendors have not anticipated and co-operated) that they provide declarative tags for the things that are currently implemented using scripting. Why don’t we have tags for menus, for trees and so on?

One of the projects I have been working on involves creating music synthesizers in software: there is a
ubiquitous API called VSTi that most music host applications
support. These little VSTi plug-ins are usually highly skinnable: in fact there is even a “skinning community”
of people who make knobs, WinAmp skins, Java Looks and Feels and so on.

Now if I want to add a knob to an HTML page, say to select a value, what are my options? I could download some
kind of JavaScript and animations, or some Java applet, or some VisualBasic (or whatever we call it now) control. If I want to do it in markup, I have to wade into SVG, so that I can draw circles and construct things from primitives and bitmaps. Utterly inconvenient. And the result is that while the dashboard “bells and whistles” GUI is thriving like never before, especially in connection with media-related applications, the WWW is essentially knob free.

The main project I have been working on is, to me, an even starker indication. My company, Topologi, creates various analytical tools for high-end SGML and XML publishing. (We are just delivering our newest offerings,
by the way.) We build a lot of these on a special kind of Web browser, “TreeWorld”, that exchanges and displays tree data rather than HTML data. Like original HTML, we don’t try to do everthing: the model is a simple REST model, where
you select a displayed branch or branches and send that as a request serialized to XML to some URL with an action request. Then the response comes back (asynchonously) as XML (simple SOAP), with indications of whether to replace the original branch, open a new tab, append it, etc. The XML also has simple formatting hints, such as decorating GIFs and so on.

Now functionally, there are probably hundreds of systems for displaying trees on web pages using JavaScript. Indeed, we have a couple in-house too. But the point is not so much that we are viewing trees (they are a basic and common component), nor that our trees are generic XML rather than a specific vocabulary (allowing extensibility). And not that this kind of system has a great network effect, because you can link between trees sourced from different URLs so easily. The key point is that the data transferred is 100% declarative not programmed: we just send data, and the data usually requires very little transformation from the source.

HTML has largely stagnated because the W3C et al (and, I say this with enormous respect for the people at W3C, who have to cope with lots of different forces, from reactionary to visionary) because there has not been a systematic program to look at applications (web applications, applets,
web-enabled applications) as the prime source of uses cases
for new tags for HTML. Microsoft’s XAML and Netscapes’ XUL are both reactions to the stagnation of HTML, undoubtedly not entirely innocent ones, and also steps backwards:
large, systematic proprietary APIs that expose a native/extensible set of controls.

I know that knobs are good, and make interaction much easier for some applications. I know that trees are good, and make interaction and access much easier for some other applications. I know that most web-applications or web-enabled media programs I use have trees (and menus) or knobs. They are a nice size of object to work with, and to skin.

It will be interesting to see how the WHAT Working Group goes: I am hopeful something good will come out. But how to get these kind of objects standardized and available on HTML web-pages without an enormous “W3C Standard Rotatable Virtual Graspee Object, Event, Behaviour, Styling and Canonicalization Markup Language and Primer” (SRVGOEBSCMLAP) being made for knobs, or something worse for trees? I don’t know…

But I am sure that the approach of providing straightforward elements in HTML for the kinds of things
that people are forced to do in JavaScript is the best approach. (XML Forms is probably the technology closest to this following this approach, and I am glad to see that the WHAT vendors look like supporting it.)

Do you want more knobs on the Web?

I have been snuffling around various Java APIs relating to XPath this week in order to implement draft ISO Schematron in Java. But the current batch of Java APIs seem to be missing the functions I need: this must be holding back other developers too.

XML is a great notation compared to some binary data formats because the information typically comes pre-sorted: meta-data before primary data, primary data before secondary data; documents that are organized sequentially to follow the access order of a typical* client program reduce the best-case latency (the time from when a document starts to arrive until the earliest time the application starts to produce output in response.)

But this streaming advantage disappears when using DOM (in its current implemations, and I gather than XOM and JDOM are the same). What we need in the Java Standard Edition is a JIT implementation of DOM which allows early blocking read-access: a load function that returns as soon as the first element+attributes are available, blocking methods for mooching around the DOM, and perhaps an error listener for when the document is not WF or valid. If you just wanted to access the DOM in document order, the latency would be similar to using SAX: when a node arrives, you can use it straight away.

The various Java libraries around does not seem to have a way to ask, of a node in a DOM, “Do you match this XPath?“, except by the brute force way of iterating through the document finding all nodes described by the XPath until you find the node.

This cripples XPath and forces us to write our code in a certain way (or, more likely, to abandon XPath). Instead, we need an XPath implementation that rewrites the XPath to start from a given node then see if its conditions match.

Finally, the Java DOM libraries do not seem to have a way to iterate through a document according to various stragies and dispatch to various functions according to which of several XPaths has been matched: .NET apparantly has functions for this kind of thing.

Are we supposed to use XSLT calling external Java functions for this? Here is the kind of thing I would like for a dispatching API:

  DomDispatchingIterator d =
     new DomDispatchingIterator( someDom, TOPDOWN,
        {"/x/y/z", 1, "/x/z", 2, "c[@d], 3 } ) ;

  while(d.getNext()){
    switch(d.getPathCode()) {
      case 1:
        // handle /x/y/z
        break;
      case 2:
        // handle /x/z
        break;
      case 3:
        // handle c[@d]
        break;
      }
   }

* Some people will scream “But in XML you don’t/shouldn’t/daren’t/dursen’t/won’t have a
typical application in mind. Well, I think people
often do: it impacts design choices. And then
by publishing a DTD or schema, designers promote
applications to follow that typical structure.

Does anyone know any Java libraries that provides these functions?

Related link: http://tinmith.net/

Augmented Reality (AR) has been an emerging technology for a while now. As far as civilians are concerned, there certainly aren’t many practical implementations of AR to speak of. I know this must be the case, because every time I mention it to a friend or colleague, they graciously smile and nod.

AR represents a form of computer graphics that is displayed (various ways, usually using some form of headset) on top of the real world in front of a user. This could range from a user seeing the names of restaurants floating in front of him while walking past them down the street. Or it could be seeing the location of an airstrip while looking down from an airplane in the dark. Just think of any type of computer-accessible information that could be geographically linked and imagine being able to “see” it right in front of you.

I want to see AR applied to my area of interest - mapping. While certainly AR has some strong ties to locational information in general, it could serve a very specific purpose in various industries using Geographic Information Systems (GIS) and mapping. Many of the key data requirements for AR are readily available in GIS data managed by government and industry, specifically that of Digital Elevation Models (DEM).

We produce a lot of maps for field crews working in the forest. It would be great if they could have those maps digitally available through AR - projected in front of them. They could find the road turn-off to their work area easier, as it gets drawn as a thick line in their display. They could see the boundaries around their areas without having to hunt for small plastic ribbons tied on trees every few meters. Or, better yet, they could fly over areas in a helicopter and look down seeing their areas outlined in red on the ground. Then take it one step further and allow the user to virtually “draw” on the landscape below, having it stored in their database for reference back in the office. All this capability is shown well in real working examples at the http://tinmith.net link above.

This may sound so unnecessary and a “nice-to-have”. But consider what happens with those hardcopy maps when they are out in the field. A continual process of matching mapped features to the real world occurs, over and over again, as the user goes through the day. The same thing that AR does but much more efficiently and way cooler!

I believe it’s time to liberate that data from 2D conventional maps and start getting up front and personal with it in the real world. We need to start getting comfortable to wear wearable computer hardware including motion tracking devices and unintrusive head mounted displays. A lot of current prototypes are large and wouldn’t hold up in my outdoor environments. But, I think the software is ready to be applied.

Wayne Piekarski’s Tinmith project at the University of South Australia’s Wearable Computer Lab has given me the hope for several years (now), that a usable and affordable solution is no longer just science fiction. Holodeck move over.

Download Wayne’s demo videos , then check out what it’s like to play Quake using AR!

Like AR, hate AR, sick of 2d maps? Let’s hear it! If you want to see this type of thing “happen”, let me know.