I like GROKLAW and think Microsoft is always worth the wariness you should afford any territorial bull elephant, or even a meek kindly HIV-vaccinatin’ elephant,
but a recent GROKLAW article
about Microsoft joining the US committee which will deal with some technical and procedural aspects of ISO standardization
of both the OASIS OpenDocument Format and MIcrosoft’s proprietary competitor through ECMA disappointed me.

I have been involved in that world (ISO SC34 in particular) for more than a decade now, and her (GROKLAW’s) concerns do not seem realistic to me.

… otherwise know as …

Okay so my last post was meant to be a combination of showcasing the importance of XSLT in the here and now and in the future, and to do so with some fun involved… It was also meant to lead into this post (now maybe the little side show regarding elevator music makes more sense?), one right after the other, but believe or not I got distracted by a thing or twelve and am only now sitting down to write the follow-up. :D

Alex Bosworth’s Weblog: Web Kills Copyright

Today , copyright infringement has never been more widespread, because it’s not about republishing, it’s about communication.

Wow.

So the above quote comes from one of the best summaries I’ve seen of why the current copyright law in place, and even more so how this so called copyright infringement isn’t that at all, and instead simple communication of which doesn’t require the need for EXTENSIVE and DESTRUCTIVE laws and legal actions taken because of these laws to ensure that peoples “property” is protected from “thieves”.

It doesn’t. And it seems to me that Alex has every intention of following in the footsteps of his Father in regards to his leadership ability and overall understanding of how stuff REALLY works in this world, to then act upon this knowledge, creating good things with this ability/skill and knowledge instead of destroying the potential for these good things to ever even exist in the first place.

Thanks Alex!

So three things:

… otherwise known as,

Premature Male-Pattern Baldness

Alex Bosworth’s Weblog: Ajax and XSLT in Web Development

I especially like Google’s choice to be agnostic about namespaces, as XML namespaces make me want to tear my hair out.

I tell ya… I was this >< close to taking this piece and dissecting it into billion little “Itsy-Bitsy, Teenie-Weenie, Here’s A Phreakin’ Clue For Freebie” pieces… (and there are about 15 places that, in fact, made me want to rip out my own hair! Just not for the same reasons. [hint: XML NAMESPACES ARE MIND NUMBINGLY EASY TO UNDERSTAND!!!]

That said, here’s why I chose not to:

This is the second in a series of articles I’m writing about the ongoing XForms implementation in Mozilla Firefox, with the previous article being Why XForms Matters, Revisited. Then next article in the series is Understanding XForms: Components

When you talk to people who’ve heard about XForms, they like the idea in theory … until they encounter an actual XForms example. There’s a brief period of shock, a momentary glazing of eyes, then inevitable the utterance, “but it’s so … complicated!” Then they run off to the WHATWG Web Forms 2.0 project, and continue to spend man-years attempting to script what they could have had free.

It hasn’t helped that some of the most prevalent examples have been things like calculators, especially since calculators can actually be implemented in far easier fashion with straight Javascript on an ordinary HTML form, with XForms being overkill for it. The other “canonical” example is a W2 Form - and to be perfectly honest, while this actually is a better use of the technology, it is far too complex to be very canonical.

What I wanted to look at in this particular article is a much simpler walk through to put together an XForm based application that illustrates that it really isn’t that difficult to create an XForm - you just have to have an understanding of what exactly XForms really are.

via a recent post to the Microsoft Live Clipboard discussion list [join, 03/2006 archives], Paresh Suthar reports:

Temporary location is at http://spaces.msn.com/editorial/rayozzie/demo/liveclip/specification/v091.html

Please provide feedback/comments by posting to the discussion list at
http://discuss.microsoft.com/archives/live-clip.html.

[EXTENDED-UPDATE: Just as I had hoped there has been a significant demand for both the stream and the downloadable files. As such as I have posted the zip file to a second server which should provide a much higher download speed as well as a torrent file.]

Location One (prefered)

BitTorrent File

Location Two (backup)

via Doug Kaye the following two links will provide even more links and content relating to Free Culture. Thanks Doug!

[http://akma.disseminary.org/archives/001256.html] : [http://www.itconversations.com/shows/detail111.html]

via Scott Matthews the following link will open up a pretty sweet little “mini-reader” in which you can access each individual audio chapter. Thanks Scott!

[“Free Culture” popup audiobook]

Also, I spoke with Professor Lessig in email after posting this and discussed setting up a discussion forum in which folks who have questions, comments, etc… can utilize as an ongoing conversation regarding Free Culture and the topics presented in each chapter. He liked the idea, so I set the forum up on ChannelXML, of which I have broken down into sub forums, grouped by chapter name.

If there are more links that I am unaware of, please let me know either through email, via a comment below, or via the above linked forums and I will be sure to update this list.

Thanks everyone! This is GREAT to see so much community involvement! I believe this is EXACTLY how we can all help bring the summarized message of Professor Lessigs title into a reality, helping to eliminate the perceived need for destructive copyright law by showcasing to each of our local, national, and international communities that these laws are simply not necessary, and in fact do more damage than they could EVER do good speaking in terms from both the commercial and creative side of the overall package.

In other words:

Current copyright law minimizes (in fact it STIFLES creativity in many regards) creativity by minimizing the incentive for artists to create.

Creativity nurtures commercial viability. If you minimize creativity, you minimize marketability.

Seems pretty straightforward to me :)

[ORIGINAL POST]
: eXplorations : A Weekly State of the IT Industry Podcast Hosted by Kurt Cagle & M. David Peterson

Free Culture, a book by Lawrence Lessig, creator and CEO of CreativeCommons, is quite possibly the most important piece of literature for our modern day culture in regards to copyright law, and the current state in which it imposes upon our freedoms. Through permission received directly from Professor Lessig, we have created a commercial free, and freely accessible audio stream that will be running 24 hours a day, 7 days a week, 365 days a year for the rest of eternity, or until Professor Lessig were to request for us to discontinue this stream, whichever comes first :) We encourage you all to take a bit of time out of your schedule each day and listen in on this wonderful gift we have been given by a man dedicated to bringing about necessary change in our copyright laws such that we can truly live in a Free Culture in which the freedom to create, not destructive copyrights, prevails above all else.

For personal reasons I needed to take a day+ off of work and as such there are still a few more details to finish up for the new interface into Kurts and my “eXplorations” podcast website. However, I don’t want to allow my own inefficiencies to get in the way of announcing the above, which is what you will currently find on the front page of the above linked site.

As soon as I have a chance I plan to add a downloadable version of this audio title such that you all can download and listen on-the-go to what many folks, including myself, feel to be the most important work in our modern day in bringing about a widespread understanding and subsequent change because of this understanding to the current state of destructive copyright law here in the United States and abroad.

Thanks for taking the time to listen. This stuff is REALLY important!

A special thank you, as well, to Professor Lessig for allowing us to create this stream, and for giving this world such a wonderful gift in Free Culture, Code, The Future of Ideas, Code v.2, and, of course, Creative Commons. Folks like Lawrence Lessig come around once every third generation or so. I guess our generation just kind of lucked out :)

PLEASE NOTE: Sylvain and I are watching the server we have this streaming from like a hawk. If necessary, we have a backup server ready to go to handle any extra load this announcement might bring. We are also prepared to add as many servers as necessary to handle any load thrown at us. In other words, bring it… we’re ready. But also, if theres a hickup or two, adapting the system to handle the extra load will be the reason why.

Jonathan Robie’s XQuery Blog

Jonathan Robie’s XQuery Blog
XQuery, XQJ, Data Integration, XML, Databases, and the Web.

So I knew Jonathan Robie (fifth name down… yeah, in case you were unaware, Jonathan kinda knows a thing or two about XQuery ;)) had started a blog a while back. But it seems he has gone from his once in a blue moon post’s to once every day or two.

SUBSCRIBED! :)

No one ever got fired for… Copia

So no one gets fired for Google-like systems architecture. No. Outside the crescendoing Web 2.0 bubble, no one gets hired in the first place if there’s the slightest sniff they’d contemplate such a thing. Shame. Web 2.0 is not a bubble (square-one-dot-com) because it’s based on near-trivial technology. It’s a bubble because there are very few opportunities for arbitrage in a marketplace whose point is to provide customers unprecedented transparency and choice. The very place where such an approach can more consistently provide value is within the enterprise whose information systems have so long been bantustans of baroque and isolated systems. The enterprise is where there is a real chance of information systems revolution from Google-like technology. And it’s the one place where no one is looking to build and deploy technology the way Google does.

Yet Another Fantastic Post from Uche. I could not agree more with ALL of this.

Two things to point out:

After reading Savas and Jim Webber’s blog entry on the latest release of WS-Eventing I decided to have a read. Here are the highlights

• Defines 3 actors, the Event Sink, which is the consumer of the event, the Event Source, which is the event generator and the Subscriber Manager, which is responsible for managing subscriptions

• The Subscribe message is sent to the Event Source to create a subscription. The subscribe can specify a filter clause to constrain the type of events it receives. The subscriber also specifies the duration of the subscription.

• The Renew message is sent by the Event Sink to the Subscriber Manager to renew an existing subscription.

• The GetStatus message is send by the Event Sink to the Subscriber Manager to retrieve information about the specified subscription. This message will return the expiry time of the subscription.

• The Unsubscribe message is sent by the Event Sink to the Subscriber Manager to delete the subscription.

• The Subscription End is sent by the Event Source to the Event Sink to terminate a subscription.

• Once a subscription is in place the Event Source will send notification messages to the Event Sink until the subscription expires or the Event Sink unsubscribes or the Event Source terminates the subscription. Notification messages are simply valid SOAP messages.

• The specification defines the following faults DeliveryModeRequestUnavailable, InvalidExpirationTime, UnsupportedExpirationTime, FilteringNotSupported, FilteringRequestUnavailable, EventSourceUnableToProcess, UnableToRenew and InvalidMessage.

• WS-Eventing has the capacity to support different delivery modes (i.e the mechanism used to transport notification from event source to event sink). The current specifications only supports ‘push’ delivery mode (i.e. event source pushing notifications to the event sink).

It seems that AOL is gambling with your privacy. I believe this is wrong. Here’s why:

A profound change is likely about to shake up your world if you’re a web developer, one that I suspect will make the recent efforts in the AJAX space pale in comparison as far as its effect. Very quietly, over the last few weeks, the Mozilla team has been upgrading their XForms capabilities through the use of an XForms extension. It requires that you are running Firefox 1.5.0.1 or above, or Seamonkey 1.0 or above, but frankly, there are very few reasons for you not to be at this stage if you’re a Firefox or Seamonkey fan.

More than two years ago, I wrote a piece in my blog with the name “Why XForms Matter” that examined this technology in some detail, but at the time, the level of support for XForms was rather depressingly thin. A standard formalized in 2003, the XForms 1.0 Recommendation offered up an intriguing vision - an XML based format for the deployment of form fields both within XHTML documents and within other XML environments (such as SVG, the Scalable Vector Graphics language) that would make it possible to make a surprisingly powerful rich client that didn’t have to be extraordinarily heavy in terms of memory footprint, processing power, or speed. What’s more, as a W3C standard, it could be deployed with no royalty costs, could be implemented on a wide variety of platforms in implementations that only had to be compliant to the standards, not to any development language, and couldn’t be held hostage to a company’s need to change their operating environment every time sales figures lagged for the quarter.

Raw

An interesting opportunity for independent developers for this years WWW2006 Conference:

I’m not one who chooses to watch Television all that often. I own a T.V. but I decided a while back that the amount of benefit I gain from watching T.V. as opposed to going out for a walk, or sitting down and reading a book was so far out of proportion that it simply doesn’t make sense to spend much time in front of it (with the power turned on) anymore. I do sit in front of it on occassion. But thats more about the location of the T.V. as it relates to the couch or chair I will sit in to read.

“What does this have to do with you, or the automobiles you manufacture?”

I’m glad you asked,

It still surprises me that the practice of documenting software architectures is largely unpracticed in both the open source and commercial software projects. The act of documenting a software architecture lays a solid foundation for the project. Here are some reasons why you should consider practicing the unpracticed.

1. The software architecture is a core project asset.
2. The software architecture bridges the problem space and the solution space.
3. The software architecture addresses the stakeholders concerns.
4. The software architecture is the foundation to planning and risk mitigation for the project.
5. The architecture document is a conceptual model of the solution.

A good architecture document addresses the concerns of the stakeholders and provides a context for the planning construction and testing effort. Many projects have failed because of the lack of architectural vision or the ability identify the architectural risks. Some develop an architecture document at the start of the project and put it away never to be seen. Instead it is a dynamic document that must be maintained throughout the product’s life cycle. So if you are putting together an architecture document look for tools to help maintain it. Sometimes that may be as simple as a good word processor but in other cases it may be a modeling tool with the ability to automatically generation the documentation.

Some organizations produce huge architecture documents for large systems, which are incomprehensible, inconsistent and largely irrelevant and these are organizations that are rolling out huge mission critical applications. On the subject of writing architecture documents I adopt the ‘views’ approach proposed by people like Philippe Kruchen, and Paul Clements and organizations such as IEEE.

Here are some links

• Architectural Blueprints - The 4+1 View Model of Software Architecture
• The Tao of the Software Architect
• Documenting Software Architectures: Views and Beyond
• Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives
• IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems

Following on from Plotting the exact X/Y coordinates of clicks on a page, we’ve now aggregated data from a number of similar websites (including the Imperial War Museum). As mentioned in my last post, we’ve been collecting the X/Y coordinates of clicks, together with other relevant data (including: screen resolution, text size settings, user agent and “time to click”).

I’ve been looking for patterns in the data, and although there isn’t much to report, I thought it would be interesting to share what we’ve found so far:

Text Size statistics

I was surprised by the number of users who choose non-default text size settings in their browser. Although this may be due to a selection effect (this data comes mainly from Museum websites, which may have a particular audience), the figures are still surprising:

(give or take rounding errors)

With regards to ‘time to click’, I checked for a pattern, but found that there is no strong relationship between Text Size and Time to Click. I had hoped to find that users with larger text sizes took longer to find what they were looking for (either because there was less on the screen, or because they tended to be older, less experienced users), but found no evidence to support this.

I say ’strong’ relationship in the above statement because there was a little evidence: users with ‘Medium’ took (on average) 12.4 seconds to click, ‘Larger’ took 14.4, and ‘Largest’ 13.7 (for interested readers: Smallest = 14.5 and Smaller = 13.6). Although you could argue that non-Medium text sizes took longer to click, the difference is so small that a much larger data sample would be required to conclusively prove this.

Screen Resolution statistics

I was expecting to find a trend of some sort, but found that there is no relationship between Text Size and Screen Resolution. So, a user with a resolution of 640×480 is just as likely to use ‘Largest’ text size as a user with 1280 X 1024.

Using data from a single, ‘tall’ site (in design), I also checked the y position of clicks against screen resolution. Again, I had a preconceived pattern that I was hoping to detect - that users with larger resolutions were more likely to click further down the page. However, my findings seemed to prove the opposite (although again the figures are so close that we can’t conclusively prove anything):

Browser statistics

I’m not sure what I was hoping to find, but a comparison was run of Browser against average “time to click”:

So, the obvious conclusion is that Safari is the most usable web browser! Seriously, though, I can’t think of any browser-related reason why users of one product would be able to ‘find their link’ quicker than users of another browser. Perhaps FireFox and Safari render the pages sooner than the ‘onLoad’ page event (which is when we start recording for ‘time to click’) than in IE. Or maybe IE users are just plain dumber, so take longer to read and find content. I am an IE user, so I think that’s hard evidence to back this hypothesis.

Related link: http://www.understandingxml.com

If things at work aren’t too insane, after her school gets out I occasionally pick up my just turned six kindergartener and take her out to a particular restaurant near where we live for “second lunch” and a chance for her to run around the inside playground equipment (in the spring and summer, we usually go out to parks instead, but the winter is a little too unforgiving in Victoria for that). It is a not uncommon destination for a lot of the kindergarten class, so I’ve reached a point where I actually know many of the other parents well enough to banter and talk.

On one such day, I had a chance to talk to an older gentleman from Toronto, a third generation Chinese-Canadian immigrant who had come to work first in Toronto then later Victoria for the Canadian department responsible for handling maps and cartography. We talked for some time, and he laid out a story about his time starting from a young draughtsman and working his way up to being a senior cartographer. It was a fascinating tale: in the 1950s when he started, cartography was a matter of art as it was of science - you had to be adept with pen and airbrush, had to be able to interpret arial photographs and needed a fairly deep understanding of geology, property law (your work was often the reference by which lawsuits were settled), and mathematics.

What’s more, you had to be careful, meticulous, yet amazingly fast, to the extent that what most entry-level cartographers could expect would be sharpening pencils and erasing pencil marks from finished work for the first year or so. While it was considered a white collar job (one of the first such technical jobs in that designation, in fact) at the same time there was an apprentice/journeyman/master relationship that was as clear cut as any guild.

Not surprisingly, computers were devastating to the field, while simultaneously pushing it into warp drive. Computers were especially good at such things initially as plotting isoclines, relying first upon a grid of gravitational surveyer coordinates and later upon laser-based telemetry and GPS systems to plot gradients in a way that even the best map artist could only approximate with a well-painted twist of shading. Since isocline plots were especially useful maps for everything from real estate developers to mountaineers to city planners and aircraft pilots, these maps very quickly became the “next big thing” in the field.

However, in its wake, legions of skilled cartographers found pink slips on their draughting tables, including the grandfatherly figure I talked to. They were replaced by young kids who had only rudimentary ideas about geology but who were far more proficient on these new computer systems, who replaced meticulous renderings of schools, municipal buildings and houses with bright shiny symbols that came cookie-cutter like from a library of pre-approved graphics. Maps lost their artistic value, and increased the number of errors in them considerably, at least for a while.

Yet even after he’d been cashiered out, he would still get calls from the kids to come in and help them understand the subtleties of what they were dealing with. When his nephew came to him to tell him that the younger man was also going into the field, his uncle took him aside, and told him to learn computers first, then to go and then to learn his craft very, very well, to the extent that several years later the nephew ended up managing the same agency that had so unceremoniously gave his uncle his walking papers.

I then told him that I was going to speak at a conference in a few months on Geographical Information Systems or GIS (more specifically, GeoWeb 2006 on July 24-28 in Vancouver, BC), talking about the use of Scalable Vector Graphics and its emerging use in the GIS field. Unfortunately, he had to leave shortly after that, but before he left he pulled me aside and said, “be careful that you don’t let the art fade away in all the computer science.”

I’m entering Middle Age. Once, seemingly not too long ago, I was convinced that I was hot stuff, carrying with me a certainty of my own skills and talents that was, in retrospect, probably unwarranted arrogance. The cool stuff, pushing the technological envelope, taking the cutting edge wave and harnessing its power while remaining only slightly bloodied, that was all in a day’s work. I was also convinced that those who were more senior to me had earned their positions by dint of their brilliance, though that particular illusion has long since bit the dust. Finally, I think there was a part of me that readily acknowledged that I was still a boy, that my actions weren’t really that important to other people.

Lately, however, I see the gray peppering my red beard. I find losing the weight I’ve gained becomes far more difficult, and that my knees ache far more when climbing the stairs in my house than they used to. Those physical changes, however, seem to be accompanied by a growing realization of mental change, among them the realization that there is a joy to be taken in well designed code, a growing dissatisfaction when the solutions that I create are not elegant enough, and a growing impatience with younger programmers who are so eager to blaze through a project, pulling all nighters and subsisting on pizza, coffee and Red Bull to hit that arbitrary (and usually meaningly) deadline … and the almost as young managers who seem to see there is nothing wrong with this.

Perhaps I am on the edge of that same cusp that my cartographer friend faced, yet I think that there is another realization that I am also facing, one that seems to beat ever more insistently the older I get.

There is science in programming, certainly: the science of engineering, the science of algorithms, the intricate understanding of namespaces and function calls and the distinctions between imperative and declarative code. I think that a lot of schools teach the science of programming, and all too many businesses take that science and bastardize it in the name of getting the product out the door.

Yet for all of that, there is also art in programming. It is the art of the craftsman, the art of the draughtsman or the old style cartographer. It is the realization that you are reflected in the legacy of your code, that your ideas will shape and mold a generation of younger minds. It is holding your ground and insisting upon quality over speed, because you know that kludges are the shortcuts that you take out of fear, laziness or greed, and that such kludges detract from the potential for perfection in your code. It comes in studying both the new and the old, the new because from such come the seeds of inspiration, the old because this reflects the collected wisdom of programmers who struggled through the same problems and strived themselves towards the best solutions.

The irony, of course, is that as you gain mastery in this field, the field by its very nature tends to promote you up and out, putting yourself ever farther from the code even as you finally begin to come to some level of understanding about what’s really going on. I feel these pressures myself - while I still code, I find that the demands upon me to deal with the “larger issues” beyond the code, and the need to help educate the next generation of coders, grow accordingly. It is the chief’s dilemma, though most programmers would be horrified to realize that there is in fact such an analogy.

A good chief petty officer in the military comes to understand that his, or her (thanks, Sally!), value comes not in doing the tasks that they’ve mastered so well over the course of their careers as it is in both helping young seamen and petty officers learn how to master their own skills and helping young ensigns and lieutenants learn the confidence to lead and direct those under their command. It’s not just a matter of age - there are of course incompetent chiefs in any Navy (or sergeants in any army, or lead programmers/managers in the IT shop). I think that before you can become a master in any field you need to have a certain degree of intelligence, introspection, confidence, and perseverence … and the luck of talent certainly never hurts, so long as you realize that talent is simply another tool towards achieving mastery, and not necessarily the most important. That life-changing chief is an artist, a craftsman, a man or woman who understands that the ultimate goal of all art is to push us beyond what we are to what we could be.

So as you sit down to write your programs, to shape your products, to press against the boundaries of the possible, remember to not let the art fade away in all the computer science. You, and those who will live in the echoes of your legacy, will be better for it in the end.

Kurt Cagle is a writer and programmer.

Your thoughts?

As the year before, ETech featured a night of Makers exhibiting their fascinating, fun and warranty voiding work for attendees.

My favorite exhibit came from Syuzi Pakhchyan of Sparklab. Her Wearable Light and Role Play (Clothing as interface) exhibit was ingenious and quite cool. Her work started as a research project into what can be done with simple electronics and clothing as a form of self expression that evolved into a series of DIY projects. As she explained to observers one of the issues that she had to overcome with her target marker was the fear of a soldering iron. They know about sewing and making their own clothes, but picking up a soldering iron is a foreign and intimidating idea. In a stroke of genius she mixed sewing techniques with electronic materials to create forms of wearable light in clothes. Her Role Play was equally as ingenious take elements already found on clothing, such as zippers and the cords on a hoodie, and termed them into controls for other embedded electronics in cloths.

An honorable mention goes to AtariAge for its homebrew and vintage video games. (I’m a sucker for that type of stuff. There’s nothing like the classics.) Homebrew games are “new, original games for classic game consoles.” They produce these games in cartridge form and sell them on their online store. What’s interesting is that despite being the same hardware the tools and knowledge available today to homebrew games authors allow them to create games that were not possible when these systems were first released.

There was a moment of mayhem when part of the British contingent got their hands on the Howtoons marshmallow shooters. A special sniper award goes to Esther Dyson. Always a crowd pleaser.

Phil Torrone, Make Magazine assistant editor extraordinaire, was showing his hacked up remote Bluetooth-enabled Roomba bots. By the end of the night various “weapons” and impromptu gadgets had been taped onto these bots for some robot war action. Zipping precariously across 2 tables 4 foot off the floor it was more like sumo wrestling meets the demolition derby.

If only science fairs when I were a kid were this fun.

Day one’s bang continued through the energy level picked it up a notch as keynotes and general sessions began. Live Clipboard announcement made by Ray Ozzie was quite interesting. The Multi-touch interface presentation was just plain cool. Lots of coverage over on here.

On a more mundane, but still personally enlightening moment during the action I had a chance to hear Sun’s Tim Bray talk about standards development. Having lead successful efforts to standardized XML and more recently Atom, he has a unique and accomplished resume that few in the Internet world can compare.

He said the most important thing for a standards body is to not invent technology. Ideally, standards should be based on a substantial body of experience and prior art. The job of a standards working group would be to write best practices that work.

Why try and replace something so successful RSS? There are problems with the format as used today. Further complicating matters was the contentious politics surrounding the format and the fact that RSS 2.0, the most popular form for the format, had been declared frozen despite these problems. He noted that “the syndication community has always been a loud and fractious noisy place.”

The desire to evolve syndication and address the problems in a contentious community necessitated a new and separately named effort to be created. This eventually this lead to an IETF work group to be formed. Whether that was the right thing time will tell Bray said.

“The IETF brought a formal process that no one can claim that they were left out or ignored.” The noted that the core group of Atom members could have sat around in a basement for a week or two and gotten pretty close. It wouldn’t have been as good though.

Approximately 2 years after the effort began, the Atom Syndication Format has been named an official IETF specification. Currently the Atom Application Protocol (APP) is in interoperability testing and is getting close to a final call he reported.

The working group comprised members with a great deal of experience with syndication. What the IETF also brought was a formal process and great deal of know-how security. He later said “We’re probably going to get the crap kicked out of us when we send the APP around [for IETF review]. I think that is a good thing.”

In order to lead such efforts you have to have a thick skin he quips with a smile. He said the toughest part of being involved in these efforts is the “violent personal attacks” that will crop up. He notes that there is something about syndication that “flips the a**hole bit” in normally nice and intelligent people.”

Later in the day during his session presenting Atom as a case study he lampooned the two years of discussion and debate with a slide show of various depictions of war, carnage, and destruction with the Flight of the Valkyries playing.

Devising the technology is not the hard part, dealing with people and forming consensus amongst them are.

“RSS 2.0 is fine and its going to be with us for a very long long time” he said, noting that despite its problems it is good enough for blogs & straightforward news feeds. RSS2 causes real problems for more “technical” feeds.

In his presentation he listed drilled down on the problems you can run into:

• Enclosures - One? Or More?
• Silent Data Loss - Depending on an aggregators assumptions sections of content will silently disppear.
• Punctuation Pain

- Aggregators misinterpreting the display punctuation characters

• Relative Links - no affordances are made making publishing more difficult and documents more verbose.
• International Resource Identifiers support - all links must be ASCII.
• APIs — The MetaWeblog and Blogger API map poorly to RSS and are highly under specified and BAD (broken as designed).

Bray believes the Atom protocol will have a bigger impact then the syndication format. He said, “the APP is the missing infrastructure link in making the Web writable by everyone.”

The group will probably turn its attention to the auto-discovery specification. He expects the working group to disband by the end of the year.

He said he believes it will by highly beneficial to the world if there is no Atom 1.1. The Working Group was gone to great lengths to devise a well defined and powerful extension model for anyone to build on. What he expects to see is more specialized extensions be developed and standardized in varies forms. Efforts are already under way.

Bray’s posted his case study links here.

Related link: http://www.xsltblog.com/archives/2006/03/windows_steals_1.html

InformationWeek | Server Operating Systems Ranked | Windows Steals Top Server OS Spot From Unix | February 22, 2006

Microsoft’s Windows edged out Unix in 2005 as the best-selling server operating system, research firm IDC said Wednesday, marking the first time Unix hasn’t held the top spot in more than a decade.

Okay, but by how much?

Windows servers accounted for $17.7 billion in revenues last year, the Framingham, Mass.-based research company said, while Unix-powered servers took in $17.5 billion.

Okay, so by $200 million then. A lot of money no matter which whey you look @it, but in the grand scheme of the overall market, it seems things are basically neck and neck. This is a good thing. One is pushing the other and vice-versa to become better, faster, more reliable, more secure, more user friendly, more overall value = The consumer, in this case corporations and small businesses across the world, but a consumer none-the-less, is benefiting because of this.

In fact, further in the above linked report we discover:

But Windows’ moving past Unix doesn’t mean the former top dog is going to quietly slink away, IDC analysts said.

“We do not believe that any one platform will be in a position to force another platform out of the marketplace for many years to come,” said Jean Bozman, vice president of worldwide server research, in a statement. “End users [will continue to] utilize a mix of operating systems in their infrastructures.”

Cool. So here’s my next question.

What about Linux? I’m assuming that given the fact that its an OSS product, that can be downloaded and used for free, the number must be laughably small in comparison, right?

Linux, the open-source offshoot of Unix, accounted for $5.7 billion in server sales during 2005.

*COUGH* I’m sorry *COUGH*|*COUGH* how much was that again?

Linux, the open-source offshoot of Unix, accounted for $5.7 billion in server sales during 2005.

For a free OSS system?

Hmmm… I’m trying to think:

Free != $5.7 billion, right?

[WW:Ether “Correct.”]

K, just checkin’.

So then how… wait… hold up… let me put this into something more tangible:

So what you’re saying is that Linux *DOES* have a business model that works?

But…

Okay, whatever… Nevermind… I’m still confused by all of this, but no doubt the numbers are correct and folks like RedHat, Suse/Ximian/Mono/Novell, IBM, etc… have figured out a good and proper way to make a business out of free software, and do so in a way that doesn’t cause the various OSS communities to revolt due to any notion they felt they were being taking advantage of… Something that always felt to me like it would eventually become a problem. These folks are not idiots. If they felt they were being taken advantage of it, we would know, I promise :)

All right, cool. Still don’t get it, but me not getting how they are doing it should be something for me to deal with, and not get in the way of simple acceptance. As such, accepted… Now lets move on.

Let’s get some growth rate figures:

The trend of Microsoft besting Unix appears to be accelerating, noted IDC. Windows server sales climbed 4.7 percent in the fourth quarter of 2005, year-over-year, while Unix server revenues dropped 5 percent. Linux, meanwhile, posted double-digit year-over-year growth: fourth quarter 2005’s numbers were 20.8 percent higher than 2004’s.

Okay… so lets do some math.

—
Windows Server: +4.7%
Unix-based Servers: -5%

Total un-accounted for sales difference: 0.3%

Linux year-over-year growth*: +20.8%

Market Share:
It would be impossible to determine actual market share using the dollar figures presented, as market share (as long as I understand it correctly) is a representation of total number of new licenses sold as well as the total number of existing licenses currently in place. Without knowledge of the average cost per license it would be impossible to derive what that number is.

Now, I might be able to find that information if I looked… but I’m too damn lazy, so we won’t bring this into the equation until such time as the research effort seems justified in comparison to the amount of extra time I have each day to do such research. Not high on my list at the moment. Probably will never happen because of this. Sorry.

So, moving on lets pretend for a second that if we add up the sales of the above three represented systems, and setting aside the fact that there are going to be systems sold that are not represented by Windows, Unix, or Linux:

17.7 + 17.5 + 5.7 = 40.7 Billion US dollars in total server software sales during 2005.

Firstly, HOLY #$*!! Thats a lot of money!

Secondly, HOLY #$*!! Thats a lot of money!

Thirdly, HO… nevermind.

Fourthly, (if (40.7 == 100%) then ((5.7 div 40.7) = 14%) == true)

If the result of the above equation is, in fact, true, then setting aside the fact that total sales != market share here’s what were looking @:

With the notion that Linux sales are 20.8% higher in fourth quarter 2005 compared to fourth quarter 2004, and adding to this the fact that there is a 0.3% unaccounted for difference in sales growth between Windows and Unix, then I think we can accuratelly state:

Linux needs to be given a lot more credit than they have been. While it goes beyond this, lets look at two things Linux has proved:

* There *IS* a business model in OSS, and in particular Linux OSS
* Its time to start taking OSS software a lot more seriously than we have (if in fact “we” includes you. If you already take it seriously, then please remove yourself from “we”. Thanks! ;)

Now, with that said, I have my own feelings on what qualifies as a legitimate OSS product and what does not. Or better said, what qualifies as an OSS project that can be seen as beneficial to the Free Market Tech Economy, and one that can be seen as destructive to the Free Market Tech Economy. But I would prefer to not make that a primary point in this post, and instead keep Linux, a legitimate OSS project that is beneficial to the Free Market Tech Economy, as the primary focal point for this section.

Summary

Here’s what I think we can safely derive from all of this:

* The server software marketplace is alive and well
* Windows Servers needs to be given some credit by the folks who otherwise would not give it credit, for being a pretty kick a$$ server software system.
* Unix Servers need to be given credit for fighting tooth and nail and maintaining a solid piece of the server software market share.
* The result of these last two items is a better product that is more secure, reliable, efficient, and beneficial to all of us because of this.
* Linux, and the OSS movement in general need to be given both credit, and some serious respect for accomplishing what they have thus far.

These are all good things. And each one of use are benefiting from each piece of the server software puzzle because of this.

Thats pretty fantastic if you ask me. :)

Enjoy your knowledge that we have a strong, healthy, and interesting server software marketplace that is being fueled by strong competition, including Linux and Open Source Software in general, and we’re all better off because of this-enhanced day! :D
—

[*A comparison of last years fourth quarter compared to this years fourth year quarter (speaking in generic “year” terms)]

So is the server software market as healthy as I’m suggesting? Or am I missing something that needs to be accounted for?

ETech
began out here in San Diego with a bang. No really. Like
my Powerbook hitting the curb in front of the Manchester
Grand Hyatt as I was stepping out of a cab. My baby survived
other then a small dent and some scratches to her aluminum
casing. Oh well, she’s got a lot of miles on her.

Yesterday I had the privilege of sitting through Designing the Next Generation of Web Apps,
a tutorial lead by Adaptive Path’s Jesse James Garrett and
(now) Google’s Jeff Veen.

As a career coder I’m always working on my understanding
of design and experience to create more useful software. The
duo’s presentation did not disappoint.

The broke designing a web applications into 5
elements:

• Strategy - what is this thing
  about? who is it for? what is it supposed to do for
  them?
• Scope - what is it? supposed
  to do?
• Structure - how do those
  fit together?
• Skeleton - flesh
  those out. how do they become real?
• Surface - how do we make these visually
  work effectively?

They begin with the abstract and work their way down to
the more specific.

People typically have one of two views of the Web that
bring preconceived notions

• The Web As
  Information. i.e. A newspaper.
• The Web As
  Application. i.e. Software.

They noted that it’s both though and we need to look at
it both ways and continued to drill down through these 5
elements.

One important and reoccurring theme was the issue of
giving up designers in complete control. Designers should
create a container for users to have an experience in. They
must trust the user and see them as peers. In next
generation web applications users control their data.

Garrett is known for having coined the term AJAX
(Asynchronous JavaSscript and XML) just over a year ago. He
addressed this briefly noting that AJAX is about an
asynchronous interaction model and browser-native
technologies. “Forget the rest. This is what matters.”
Quoting Bruce Sterling he said AJAX is “Roller skates for
the web!” It helps you glide along faster and more
effortlessly then walking, but it takes some time and practice
to get good at it. They can also be more dangerous. He
predicted that for the next 2 years we will see a lot of bad
design choices in the use of AJAX.

One of the most useful discussions for me was that of
context which they described as a sense of time, place and
meaning.

• Why is this happening?
• What
  can do here?
• What happens next?
• Where they
  came from.
• Where they are.

Also covered was the first impression. Earlier in the day
Veen talked about a study that had performed were subjects
were shown a screen shot of a Web site for 1/20 of a second
and then asked whether they trusted the site or not. Results
were consistent across all subjects to which they trusted
and which they did not. The first impression of the surface
(look and feel) is quite important. Further users will ask
what is this thing? What does it mean? What should I do
next? Each screen needs to address these questions for the
best possible user experience.

With time running out, the duo noted that unlike the days
of monolithic applications or the “sticky eyes” mantra of
Web 1.0, “your site is just one piece.”

Related link: http://www.understandingxml.com

Over the years, I’ve noticed that in programming, as in other systems, there seems to be a fairly invariant rule out there:

You can never eliminate complexity from a system, you can only move it from place to place.

or, put another way,

In any program, someone will have to deal with the mess when it hits the fan.

This is part of the reason why I have become convinced that the profession of programmer will always be needed. You can create boxes that can abstract away the complexities of dealing with repeat processes … this is the whole idea of component development … but by doing so, you are also intrinsically subscribing to the limitations that these components have to help you model your own environment. In some cases, the programmer was also capable of incredible foresight, making the components more flexible, but that flexibility in turn also increases the complexity of the applications using the components.

Additionally, components are typically designed to solve a given problem which is usually almost, but not quite, the problem that you need to solve. It is this impedence mismatch that forces programmers to have to use some of their own brain power, and the resulting solutions introduce complexity into the system again. A good software designer knows how to insure that the complexity stays on the programmer side of the divide, not the user’s, but someone still has to pay the price.

I’ve been thinking a lot lately about abstraction. Abstraction is a complexity management tool. It replaces a block of code with some form of interface that hides the intricate details of that code behind something that is more manageable, though typically at a dual cost - it introduces an overhead penalty to the code that is invoked every time the abstraction is called (meaning that you need to increase your performance in general to compensate for this) and it reduces the level of control that people using the abstraction have to deal with the underlying actions performed by the code. Admittedly, there are times where these costs are well worth it. A prime example that I’ve had to deal with recently has been the use of the XPathEvaluator method within the Mozilla Javascript space. It’s normal operation is an enormously complex undertaking, comparatively speaking:XML

//var elt = some Element
//var xpath = some Xpath expression
    var xpe = new XPathEvaluator();
    var nodeArray = [];
    var result = xpe.evaluate(xpath,elt,xpe.createNSResolver(elt),4,null);
    while (res = result.iterateNext()){
        nodeArray.push(res);
        }

This takes an element and an Xpath expression, performs the evaluation, then pushes the results into an array (nodeArray). If I have to do such an expression evaluation twice, I’ve needed to add sixteen lines of code - thrice, twenty four lines of code, and so forth. It seems a good candidate for abstractionfirst, to reduce its inherent complexity:

Element.prototype.getNodes = function(xpath){
    var xpe = new XPathEvaluator();
    var nodeArray = [];
    var result = xpe.evaluate(xpath,this,xpe.createNSResolver(this),4,null);
    while (res = result.iterateNext()){
        nodeArray.push(res);
        }
    return nodeArray;
    }

This does a number of things. First, by associating it with the prototype for an XML Element, I make the getNodes() method available automatically to any XML element:

var pNodes = document.documentElement.getNodes("//div");

This returns all <div> elements in an XHTML document. Additionally, I can also use it to extend other objects, such as the document node itself:

Document.prototype.getNodes = Element.prototype.getNodes

(which neatly eliminates the need for type-checking within the expression itself - only those elements for which the prototype has been extended will have the method in the first place).

The question here is what you’ve lost by this. In this particular case, you’ve lost the ability to specify the types of objects returned by the evaluator, which means that while you can get a set of nodes back, you couldn’t get a set of text string values or numbers from the getNodes() method. You lose the XPathResult object, which has a few additional properties that are useful for creating data snapshots. There’s a tradeoff here, in that you lose a certain level of control with the abstraction. You also add to the overhead of DOM usage, since every document and element now contains an additional pointer (and supporting infrastructure via the prototype mechanism) pointing to this particular function.

What’s more, you now have to document this addition, have to make it available as part of a general library, and have to maintain any changes to it. This is where things get a little more complicated. You’ve traded off programmer inconvenience for an administrative inconvenience. The complexity has moved, and what’s more its moved out of the code and into the realm of the coder. Again in this case the trade-off is generally worth it - if you have the process already in place, the addition of this code into a project code base will take a comparatively small amount of time, and once done, maintainance is not much of an issue here.

However, even here you run into other problems - perhaps someone has solved this problem in a different way. Perhaps someone is using the older selectNodes() method from Internet Explorer, which doesn’t return an array but a nodelist, so if you want to support common code you’ll need to come to an agreement with them about what the final interfaces should be. The point here is that such abstractions usually add to the complexity of the process in other ways, and the role of both programmer and program manager should be to determine at what stage the abstractions are worth taking.

One reason that I see this comes from recent examinations of software methodologies. Many older software methodologies tend to look upon software development as being largely a top down process of establishing formal objects then building the APIs that support these objects. Yet if you look at the model above, there is a strong push-back pressure that emerges from this abstraction process, something that typically becomes evident only when the level of complexity forces the need to develop that abstraction in the first place. It can of course be argued that good design would reduce or eliminate this abstraction, but this to me assumes that programmers are in fact perfectly capable of anticipating a wide variety of unintended consequences not only from their own code but from the code that other people create which ripples through and interacts with theirs.

To me, this is frankly an absurd assumption, especially in those situations (which are increasingly the norm, not the exception) where people do not have even marginal control over the code not immediately produced by them personally. Indeed, far from working within clearly defined silos, I believe that a big part of the reason for the sheer level of complexity today is precisely because programming is more like an odd form of field theory, where the software extends while beyond its immediate state of execution and may in fact have repercussions and consequences far removed from their initial domain. One could almost think of millions of small sub-etheric particles called Codeons, whipping back and forth through the quantum sea of ideas before impacting, wave like, upon the developer’s world, affecting everything that he or she does in the realm of writing code.

Understanding this gremlin of abstraction, the fact that such abstractions tend to be pushed up the stack as much as they tend to be imposed from on high, I believe will be essential for us to move forward into ever larger and more networked domains. The current fashion has been largely to deprecate these bottom up abstractions, to see them as being “bad practice” as they distract from the cookie cutter view of programming that seems so very evident from the textbooks in the field, and yet I suspect that what this is instead is a manifestation of the Complexity Rule at work. I as a programmer working with your APIs will try to simplify my task as much as possible, while you as the API developer will attempt to do the same on your end. Leanrning how to balance between the two, learning to provide a give and take that moves the programming contract away from one unilaterally imposed by the API provider into a more equitable relationship, will, I suspect, prove to be the catalyst for the next generation of programming.

Kurt Cagle is an author, software developer and incorrigible blogger. He lives in Victoria, British Columbia, Canada, where he writes white papers, books, articles and fortune cookie sayings (the last being his most lucrative sideline).

Related link: http://www.understandingxml.com

I recently had a chance to spend a few days talking with the CEO (David McInnis) and the key investor (angel VC Mark Effinger) in PRWeb (http://www.prweb.com). Now, lately when you refer to Web 2.0 the images that pop to mind are garage-band start-ups run by pony-tailed twenty somethings (albeit, very smart ponytailed twenty somethings) creating some new web community or photo-sharing application. I’ve lately been fortunate to talk to a lot of these companies, some with obvious investment potential, some that even the owners admit exist solely to scratch an itch. However, when I had a chance to look deep into PRWeb, what I saw was what Web 2.0 companies will become.

PRWeb deals primarily with press releases. In the information economy, press releases have about the same immediate “excitement” factor as nuts and bolts and screws do in manufacturing. They aren’t sexy. They are created in their tens of thousands each year by writers who ended up getting sucked into the marketing engine, and they have to carefully walk the line between useful information and advertisement on a daily basis. However, there’s something to think about when discussing nuts and bolts and screws and flanges (and press releases). The people who manufacture them are usually very wealthy, because they deliver something that everybody uses on a daily basis, and that every business and organization needs to provide (and thus purchase) on a daily basis. This is a numbers game, a volume game, the only difference being that the commodity being sold are not physical connectors, but virtual ones.

Let me illustrate what I mean by an example. First, I happened to see the announcements of a new podcast magazine (ID3 Podcast, which will be covering the emerging Podcast industry - within the space of a few emails I had managed to secure a column. Then I stumbled across some activist blogging group (with a philosophy somewhat opposed to mine, so you’ll excuse me if I don’t link it, which I sent off to a couple of activist groups that I do believe in, letting them know what the competition is doing. A couple of conferences that were more or less in my domain also crossed my deck, not to mention several products that I will likely be following up on to do reviews here or in one of my other media venues.

In an industry where information is coming to you fast and furious (and where the visibility of the future is as a consequence surprisingly limited, precisely because there are SO many possibilities to sort through) press releases provide an invaluable tool for cutting out the intermediate chatter of pundits and opinion shapers. Just like a professional stock broker isn’t going to rely upon money.com for his or her analyses, neither should a professional information manager rely upon material that is weeks or even months out of date. Thus resources like PRWeb are invaluable.

The fascinating thing about the service however is the fact that it is nearly literally in the middle of farmland. The new corporate offices are located in Ferndale, Washington, a sleepy little town of maybe 10,000 people just south of the US/Canadian border, and consist of a largish former VFW Hall and yoga studio that have been renovated to house the editorial and management offices for a company of perhaps thirty employees. Despite this, PRWeb is no doubt giving companies like Reuters and APIs nightmares, because this very Web 2.0 company uses the jujitsu ability of syndication services as a wedge to reshape the landscape.

As a reporter and periodic application reviewer, I rely fairly heavily upon press releases to both notify me of new tech and to keep track of emerging trends. You have to take most such releases with a grain of salt - they are intended, of course, to provide a favorable review of a given product or service, and the role of a good reporter (or reviewer) is to sift through the actual application in order to find out how closely the hype lives up to the final product. However, most reporters over time tend to develop a pretty good BS detector for sifting through the bias (although they may of course introduce a bias of their own in the process of reviewing).

What changes with companies like PRWeb is the concept of syndication and syndicated filtering. Until relatively recently, most PR companies managed to latch pretty quickly onto the web as a means of publishing news releases on their own site, but the problem of course with this method is that you still needed to get people to come to your site. On the other hand, if you could subscribe to a news feed (either via an email subscription or, increasingly, via a syndication feed) then you can be notified every time something comes in that fits within your general interest domain. In both cases, you are dealing with messaging targeted content to users of the service, the principle difference being the specific nature of the message.

There’s some anecdotal evidence that news feeds are beginning to eat into the more traditional domain of email. This is not an unwelcome development; while email has a well established protocol, its structural elements are more than twenty years old, and critical aspects of email, such as the way that content-enclosures are handled, make them rife for abuse (as legions of spammers have found). By moving to something like Atom, you are able to create multiple “entries” within a feed (or even an entry) are able to keep critical metadata in an easy to work with XML format, and are able to handle enclosures of different types in a transparent and consistent manner. Indeed, this seems to be the approach that GMail and other web-mail services are now beginning to employ, offering mail content in both traditional and “news-feed” served vehicles.