Related link: http://lists.w3.org/Archives/Public/www-tag/2002Sep/0183.html

After encouraging the XHTML Working Group to publish HLink, an alternative approach to XLink better suited to XHTML, the TAG announced yesterday that it was the “unanimous opinion of the TAG that XLink should be used for hypertext references in XHTML 2.0.”

Earlier yesterday, XML.com published two pieces on HLink: Kendall Clark’s “Introducing HLink” and Micah Dubinko’s “A Hyperlink Offering“.

Heated discussion is taking place on the TAG list. It’s not entirely clear that the TAG can order the change, and Tim Bray suggested a somewhat less explicit interpretation of the TAG’s announcement, but asbestos suits are recommended.

Personally speaking, I think the TAG made a remarkably poor decision, basically because XLink isn’t up to the job of interacting with existing (X)HTML expectations. Rather than being an enabler, it serves in this case as a straitjacket.

Must there be only one? (approach to hyperlinking)

Related link: http://aspn.activestate.com/ASPN/Mail/Message/xml-dev/1369293

Ari Krupnikov sends a warning about the dangerous consequences of the ever-growing complexity of the XML family of standards.

People who have been working with XML long enough may remember that XML began as a simplification process, an effort to reduce SGML to a small enough feature set that it would be easy for developers to implement and humans to use. Although the original XML 1.0 acquired a few complexities of its own during its development cycle, it was still relatively simple to implement. (I’ve personally implemented about half of it for a J2ME parser, and I hope to finish creating a complete J2SE parser in the next couple of months.)

Since then, however, the specifications have grown and grown, far outpacing the SGML specifications that XML was designed to replace. Namespaces in XML was brief, but has spawned thousands of endless discussions. W3C XML Schema has been cursed for years as an over-complicated and seemingly contradictory contraption. While XSLT 1.0 and XPath 1.0 largely avoided major controversy, their bloated 2.0 descendants are enormous, picking up huge volumes of extra features from their W3C XML Query cousin and the insistence that they support W3C XML Schema.

On the Web Services front, the arena where vendors push XML the hardest, it’s reached the point where simply keeping up with the competing specs is a full-time job, and where some are suggesting “blackmailing” vendors (just with dollars) to ensure interoperability.

Krupnikov suggests that this complexity isn’t an accident. Although some find his suggestions “conspiratorial“, it doesn’t sound all that far from business as usual by large vendors forging ahead with business plans that they can, in the end, control. Driving competitors out of the market is, after all, how some organizations make money, and if they can do it by offering customers more and more attractive-sounding features, they’ve combined marketing power with significant difficulties for their competitors.

What Krupnikov doesn’t say - perhaps it’s obvious - is that this war of attrition may not be so profitable for the rest of us. From my perspective, XML is collapsing under the weight of these features, with many developers giving up what seems like an infinitely complex system and turning to tools created by vendors who promise to ease the pain. As people turn to tools, they lose sight of the capabilities that were available in the simpler specifications, trapping themselves ever deeper in the webs of features cast by companies with a clever business plan. Larger webs catch more food, and may overshadow and starve out smaller webs.

Would you like some features with that?

Last week Sun Microsystems announced plans to offer low-cost desktop computers running open source software such as Linux, GNOME, Mozilla, and their StarOffice productivity suite in addition to identity management capabilities (via smart cards) and their portal software.

I couldn’t help but roll my eyes and be a bit disappointed. It’s not that I don’t respect Sun’s accomplishments or that I take great issue with their technical ideologies. I would also not call myself a big fan of Microsoft as a developer either. (I’m quite the contrary these days.) You have to give Sun credit for their "cahones" in challenging Microsoft for so long and continuing to live to tell about it.

According to Sun, 38% of customers surveyed are considering alternate products to Microsoft’s. Their survey also found that 90% expect software licensing costs to continue rising. Sun believes that their research indicates there is a great opportunity here. I would have to agree, but am disappointed because their announcement didn’t speak to the real opportunity at hand — to redefine the desktop and differentiate their view.

I think that Sun is too optimistic in its primary reliance on price and total cost of ownership, or TCO. It overlooks the fact that most of the corporate workforce already has a PC and applications that they are familiar with on their desks. Furthermore, replacements for the hardware are available at lower commodity prices. What is the advantage to Sun’s proposition if Microsoft modifies their licensing and pricing to close the gap tomorrow? That they are running free software and "sticking it" to Microsoft? This is not nearly as relavent to most end users as it is to Sun.

In order to make a long term desktop play and provide a true alternative to Microsoft’s vision, what we know as the desktop must be redefined, not duplicated and made "free." History is littered with the carcasses of companies that have failed to compete with Microsoft on the basis of price/performance.

The notion of redefining the desktop isn’t so radical when you consider it has changed very little despite the establishment of the ubiquitous Internet platform and its continuing evolution through initiatives such as Web services, P2P, and wireless networks. The desktop as it exists today is not suited to take advantage of these capabilities or to scale in broad decentralized deployments — like most corporate office staff that use desktop system to get their work done.

A prime example Sun should note is HomeBase DESKTOP, a task-centric Linux desktop alternative that utilizes Red Hat Linux and Mozilla developed by OEone. HomeBase includes a web browser, multiple account email, basic word processor, calendar, address book, multimedia center and a customizable personal portal. It can also integrate any existing Linux applications into the environment. OEone also offers HomeBase ANYWHERE that gives users access to their information from multiple machines or any machine with an Internet connection and a browser. It’s far from perfect, but highly intriguing and refreshing to consider.

Office productivity tools are also in need of a rethink — or perhaps a diet would be more accurate. It’s been my experience that most features in Word, Excel and PowerPoint are rarely used by most of us. Their existence only weighs down the application requiring more powerful and expensive hardware in addition to distracting and confusing the average user. I recall working with WordPerfect 5.1 and Lotus 123 over a decade ago and comparatively speaking MS Office offers me little additional functional value. (These were apps that came on a couple of floppy(!) disks and ran on 386 processors with 4MB of RAM.)

I tried out OpenOffice, the open source community version of Sun’s StarOffice, and abandoned it after a short while. While I was impressed and commend that community’s effort and dedication, it wasn’t really different from what I already had. I’m ready to switch to an Microsoft Office alternative, but not just because it’s free and not because it isn’t Microsoft.

The opportunity to provide a true alternate to Microsoft continues to develop. The key is not in duplicating it with a lower price tag, but in redefining it. I can only hope that Sun and others come to realize this before repeating history and leaving us with a promise unfulfilled.

What do you think is the key to Linux and open source on the corporate desktop?

Related link: http://dev2dev.bea.com/articlesnews/discussion/thread.jsp?thread=552

An excellent article by Tyler Jewell which explains the differences between the J2EE Connector Architecture and Web Services with respect to Enterprise Application Integration. I get asked this question a lot myself, and generally reply the same way Tyler has in this article.

The primary difference is that J2EE Connectors provide tighter integration with higher qualities of service (QoS). Web services are much looser and provide weaker QoS (i.e. transactions, security, etc.), but Web services are great when integrating across platforms (programming languages and operation systems). From a J2EE perspective, using these technologies in combination is optimal.

Related link: http://www.userland.com/whatIsStopEnergy

A few months ago, Dave Winer wrote a piece on “Stop Energy” that I really enjoyed, but for reasons opposite to what Dave meant.

It’s worthwhile to read the entire piece, but what I like best about it is Dave’s opposition between “Forward Motion” and “Stop Energy”. Forward Motion is good, progress, while Stop Energy is the destroyer of progress, keeping people from getting things done. Dave complains that “Stop Energy trumps Forward Motion every time, it seems.”

Dave’s notion of Stop Energy is sadly limited by its existence as a mirror of forward motion: “Stop Energy is not reasoned, it never takes into account the big picture, it is the mirror image of Forward Motion.” This description seems to have lost the richness inherent in the word “no”, simplifying stop energy to unreasoned negativity - it’s all about the veto. In reality, I often find Stop Energy far better reasoned than Forward Motion.

In my telling of the story, people who only push forward are like cars with only a gas pedal. Forward motion is great, but stopping makes a lot of sense much of the time, both in driving and in technology.

Creating new technologies is good stuff - if they’re the right technologies, and if they solve new problems. An enormous amount of current technological development is remarkable reinvention of wheels, and some of the new wheels are even worse than the old wheels.

At this point, after a boom of “irrational exuberance” both financial and technological, it seems like a great time to push for a break - or, even better, some reverse energy. XML got its spark by shrinking SGML’s jungle of options, before a few years of forward motion piled on levels of complexity that even SGML gurus can marvel at. Instead of asking “what new tools do I want?”, it may be a good time to ask “what tools can I do without, and what are the benefits?”

Personally, I like cars and communities that come with brakes as well as a transmission that lets them go backward as well as forward. Forward motion alone sounds great, but comes with its own set of costs. Stop Energy is necessary and useful stuff. Doing more by doing less seems to work really well as the piles of possibilities grow ever higher.

The weekend’s coming up - that’s a good time for some stop energy, reasoned or not.

Don’t you just hate it when someone gets in the way of your forward motion?

Related link: http://monasticxml.org/mirage.html

XML is powerful stuff, but developers need to take information seriously rather than expecting XML to solve their problems if they want to get worthwhile results.

About a month ago, I put up “monasticxml.org“, a deliberately unpretty site that looks at how markup works and how an understanding of markup structures might better inform the ways that people use XML. I guess it’s reasonably clear that I’m disenchanted with how most people use the stuff, not to mention the enormous baggage the W3C seems intent on piling on top of it. (At least the hype wave is fading.)

Underneath all the dreck, however, there are still some sparkling gems. Markup as a means of sharing labeled and structured information is pretty powerful stuff, though figuring out the labels and structures is still hard work, and stuff XML itself doesn’t address. Developers can make excellent use of XML, if they’re willing to stand back and look at their information separate from markup syntax and processing expectations. Create open and extensible information structures, and XML can follow.

Does ‘monastic’ XML make sense, or do developers really need a ‘decadent’ XML toolkit that does their work for them?

Related link: http://www.theregus.com/content/4/26161.html

“Web Services - that’s like so 2001.” Or so it seems, as some of the leading proponents of Web Services claim the “plumbing” is almost done and we can stop talking about this stuff.

The Register is of course renowned for its eager vulture, and Don Box has made a few controversial statements in his day, but there’s definitely food for thought here, with statements from both Microsoft’s Box and IBM’s Robert Sutor, who claims that “for the big picture we’ve only got six to nine months on this.”

Is plumbing really that dull?