Related link: http://news.com.com/2100-1017-963696.html?tag=fd_nbs_ebiz

Microsoft has apparently filed objections to the sale of KMart’s bluelight.com because of licensing issues, at the same time that CNET wonders if Office 11 will continue support for older versions of Windows.

According to a Reuters story:

““The licenses that debtors (Kmart) have of Microsoft’s products are licenses of copyrighted materials and, therefore, may not be assumed or assigned with Microsoft’s consent,” Microsoft said in its objection, filed last week.“

It must really sting for a company in bankruptcy to be told that products it paid for are not transferable assets. While I never expect Microsoft to act outside of what it perceives as its own best interest, this seems to create an entirely new category of business reasons to worry about software licensing details.

At the same time, the initial beta test for Microsoft Office 11 only runs on Windows 2000 and XP. News.com notes that:

“It’s still too early to discuss system requirements in Office 11,” the company said in a statement. “At this point, Microsoft has done testing on both Windows 2000 and Windows XP, which are both supported in beta 1 (of Office). However, this doesn’t reflect any decisions regarding system requirements in the final product.”

The release of a beta version that only supports recent environments shouldn’t normally generate massive concern; after all, the product isn’t cooked yet. However, given the fiscal importance of where that product runs to a lot of different people, maybe it’s worth paying attention if not getting paranoid - yet.

Caveat emptor? (Let the buyer beware?)

Macromedia’s annual developers conference, DevCon 2002, began in Orlando today. In his weblog, Macromedia CTO Jeremy Allaire notes, “one of the most interesting things that we’re doing is trying to leverage our community managers and other blogging Macromedians to keep the extended community of developers up to speed with what’s happening at the conference. While we’re certainly not the first group of people to religously blog conferences, speeches and events, I think we’re the first major software company to do live, employee-driven blogging of a corporate event, and certainly the first to integrate audio and video into our digital journalism toolbox.”

The audio and video postings from the conference are located here. A SOAP web services of the can be found at http://bilbo.macromedia.com/devconblog/activeblogs.cfc?wsdl. For fun and kicks I banged out a quick script that converts the data from their SOAP Web service to an RSS feed every 15 minutes. My feed can be found here.

What do you think of Macromedia blogging experiments with audio and video?

I recently attended a face-to-face meeting for the SOAPBuilders Interoperability group. The f2f was a 2 day event that was hosted at the Burlington Sun complex. I was there representing Sonic Software and Apache Axis…and also gathering some good fodder for the 2nd editition of the Java Web Services books (JAWS II). Here are my notes from the meeting.

About SOAPBuilders

<From SUN Web Site http://soapinterop.java.sun.com/soapbuilders/index.shtml”>

SOAP Builders is a loosely organized forum of SOAP vendors working towards a testbed for interoperability testing between SOAP implementations. Interoperability is demonstrated by implementing a canonical set of tests that are collectively defined by the participants in the forum.

Vendors prepare test specifications for testing interoperability between their implementations. Each vendor then publishes their service endpoints publicly so that other vendors can test their clients against them and vice versa. Any issues are then resolved through email on the discussion list. SOAP Builders is driven by quarterly face-to-face meetings, during which these tests are defined. During the face-to-face meeting, clients and service end points can be implemented, and interoperability can be tested in a “interop-athon” setting. After the face-to-face meeting, additional test development can occur, and vendors can publish their service endpoints and test results with other implementations.

The test specifications are defined by the participating vendors and classified in “rounds.” Each “round” consists of multiple “groups.” Each “group” is a collection of test specifications arranged logically. Each test specification is defined as a combination of WSDL and a textual description of the tests within that WSDL.
</From SUN Web Site>

One place to get details of the tests themselves can be found at http://www.whitemesa.net/. This latest round was focused on the “Group G” (SwA, DIME), “Group H” (SOAP Faults), and “Group I” (WSDL/XSD) set of tests described at http://www.whitemesa.net/r4/interop4.html. The current set of tests were defined at the “Round 4″ meeting.

The primary goal of the tests is to ensure that each web service vendor can serialize XML data across the wire in a form that other vendors can digest and process in their native platform. The tests are by and large based on the concept of an interoperable “echo” test. A Web service client from vendor ‘a’ generates a remote call to a service implementation that is running under vendor ‘b’s platform. This can be in the form of an RPC-style invocation or a message based doc/literal style request/response. The SOAP request is received by the service, the data is marshaled into the native form for that particular platform, then resent back to the sender. The sender waits for this response and then compares the data from the request with the data from the response. The tests range from simple “EchoString” and “EchoFloat” to arrays, complex data structures, and multipart attachments using MIME and DIME.

Attendees

The Meeting

The meeting room was set up with a local network hub such that all participants could do live testing against other participant’s implementations. However, the majority of the time was not spent on running the actual tests themselves, but discussing important interoperability issues that were already known.

Who Owns the Intellectual Property Rights, Anyhow?

There are a number of solvable interoperability issues that can be addressed by the group, but there is a bigger roadblock currently in the way. The group has no formal legal agreement with regard to intellectual property rights for anything that is “created” by the group as a solution. In recent history there have been companies that have “donated” their time to spec efforts and then chimed in later claiming ownership of the IPR for the results of the committees. I think its perfectly reasonable for a company to be cautious about its IPR. From what I hear, that’s a big reason why a number of standards initiatives are moving towards OASIS instead of the W3C (but that’s another posting in itself).

The same issue applies here. Even though the SOAPBuilder’s group is not in the business of creating specs per se, the mere act of crafting a solution to an interoperability problem could create an IPR issue. The majority of the participants thought that it would be reasonable to attempt to get the respective corporate lawyers together to resolve this, but some important few were pessimistic about the ability of their own company to agree on such a thing. Its still an outstanding issue with no owner.

The Issues

Here are examples of the technical issues on the table, and some action items going forward:

- Sessions w/ SOAP Headers. Should it be the job of the group to define “session” based conversations and correlation using some sort of conversation ID using SOAP headers? Axis has a nice feature that lets you just set a bit somewhere that says “enable sessions”. Dave Orchard from BEA jumped in and explained their SOAP-conversation spec and said we should be using that. There was some disagreement among the group about the approach because on the surface it seemed a bit different than the “session” concept in Axis. Nothing too profound that can’t ironed out.

- Hashtable or Map collection. Java and .NET both have the concept of a hashtable or a MAP collection (an unordered name/value pair collection consisting of multiple data types). There’s nothing in the SOAP encoding section of either the 1.1 or 1.2 spec to address this, or the xml-schema spec. Should a schema be required always, or can it be addressed by embedding the xsi:type for each value in the XML data. Currently both approaches are supported by Axis but .NET does not embed the xsi:type. You can’t create a HashTable in .NET and serialize it as doc/literal. There should be a serialization spec for this that everyone agrees upon. Apache Soap created one except the namespace was “xml.apache.org” so it didn’t get adopted widely. Let’s create one with a “soapbuilders.org” namespace. Axis has already implemented a serialization for “Map” data type (key/value pair). MS agreed to use that as a starting point and see how .NET barfs. Are we going to start creating specs for how this should work? Perhaps Apache Axis should be the baseline for everything? Dave Orchard has an action item to send a plea to XML-Schema 1.1 and WS-arch groups to address this. In the meantime what do we do now? Majority agrees to define it here. Glen has an action item to frame the issue and start an open discussion on the SOAPBuilder’s list in order define an on-the-wire representation of what a name/value looks like. Dave O’s plea to XML-Schema 1.1 and Ws-arch to be predicated on Glen’s discussion.

- DataSet / Rowset. Similar to Collection/Map. Rowset is a single result set, which could be treated in the same fashion as a hashtable/map. A Dataset is more complicated in that it can describe multiple tables and relationships between them. A complex (xml) schema definition is required to describe this for proper XML serialization over the wire. Currently Microsoft is the only platform that supports this well. Its unclear (at least to me) what the other platforms support. Even so, there are issues like should the test be sufficient if the clients consume the static WSDL ahead of time or should the schema be embedded in the message itself and interpreted at runtime? Microsoft supports both models. Axis would prefer inline xsi:types but that doesn’t address the complex table relation issues.

- SOAP Intermediaries. Should we have an intermediary test? Yes. Should it support WS-Routing for dynamic routing? Consensus is the vendors aren’t ready to support WS-Routing just yet. Bob Cunnings to define a simple 3 party 1-hop test.

- Async processing test.

Should we have one? Yes. Dave Chappell to work with Bob Cunnings on the intermediary test definition to get asynch processing in there too.

- Polymorphism Test - Sun to write that up. No,Glen to write that up.

- Interoperability decisions. Even if the group isn’t defining solutions, there are decisions and recommendations being made about interpretations of the existing specs that are being discussed and agreed upon. There is a great deal of “tribal knowledge” that occurs that is never documented anywhere. (Someone) to create a FAQ page about interoperability decisions that are made in the f2f meetings. Sam Ruby to take charge of editing.

- EchoDate Time zone issues. If a time zone is not specified in the date/time element of the request, what time zone should the server defaulted to? UTC? Localtime? What should the server echo back? What if a non-UTC time zone is specified, does the response echo back a UTC? The consensus is that everything should be normalized to UTC. There is also the case for a time value that should be left alone regardless. Think of a “startTime” element that one would want to use for benchmarking of a round-trip across multiple intermediaries across multiple time zones. You don’t want the intermediaries mucking with that at all. It can be localtime from the sender’s perspective because its only going to be looked at by the sender when the time value returns from its round-trip. The outcome of the discussion is that we need another timezone setting to indicate that a time value should not be mucked with….But that might have IPR issues associated with it. ;-)

- Currently there is not one definitive matrix of all the SOAPBuilder’s participants, with all their advertised endpoints, and all the cumulative test results. Each participating vendors maintains their own list with as much of the cumulative matrix as it can keep up with. Glen owns the SOAPInterop.org domain. This will be used as the central definitive place for this. Glen will point the domain it at one of Sam’s Apache machines for the hosting of the actual data.

- Fault test. SOAP 1.2 is much clearer on how to specify SOAP Faults. Can’t jump to that yet, since 1.2 constitutes a change in Fault codes that aren’t necessarily backward compatible with 1.1.

- The next face-to-face will be ~Feb 2003, hosted by Microsoft in Redmond.

Next week Sonic Software is hosting the XMLP F2F at our corporate headquarters. Keep your eyes open for a writeup.

I appreciate your feedback on this posting.

“Now the skillful workman is very careful indeed as to what he takes into his brain-attic. He will have nothing but the tools which may help him in doing his work…” - Sherlock Holmes in A Study in Scarlet

I have trouble remembering stuff.

I’m not alone, because whenever I look at a computer workspace, I see scribbled on paper and sticky-notes. Why, oh why, can’t computers keep track of this stuff better?

Right now, my brain looks more like my grandparents’ cluttered attic than the lean Holmesian ideal quoted above.

What we really need is a better way for our computers to be our brain-attics, freeing us up to do whatever it is that we do best.

So, we need to be able to enter text, and shuffle existing content into the system. We also need to be able to store email and web pages and integrate with browser bookmarks. Contacts. Todo lists. Calendars. Anything that we’re currently scribbling on yellow notes stuck on our monitors. And it needs to be searchable. Really quickly searchable, as in keystroke-at-a-time results.

Personal Information Managers (PIMs) have already been invented, right? Well, technically true, the late Lotus Agenda, Outlook, and Evolution being the top contenders. But something’s still missing: despite these programs, people still have sticky notes, or worse, a physical desktop that looks like mine.

Zoot goes a long way towards a solution, as I have written about earlier. But it doesn’t go far enough. It’s text only, and there’s a limit to maximum text size that I run into regularly. It’s also tied to a single platform, which I don’t run natively (or at all, so far with Red Hat 8)

ZOË goes quite far in this direction too, but is too focused on email. If you are, say, writing a book, your own personal notes will dominate email for the scope of the project.

Other close-but-no-cigar awards go to DTSearch, The Brain, and 4Suite, all of which are great projects, but with different goals than what I’m describing here.

If we store everything in the attic in various shades of XML, such as the current and proposed formats for XHTML, VCard, RFC822, RSS, plain text, etc., we open new avenues for use and re-use. For instance, we can uniformly display the data with XSLT and edit it with XForms. We can over time develop a desktop semantic web with rich metadata associations connecting all different kinds of pieces of our own data. The Google idea scales inward, and we will find that the links between our data are at least as important as the data itself.

So, does anyone know of such a project underway? Does anyone want to start one? -m

What do you use to keep track of stuff you’d otherwise forget? Talk Back now.

Mark Pilgrim and Sam Ruby have announced the launch of a RSS validator service. The service is optimized for the recently proposed RSS 2.0 format, but supports prior versions. This is some excellent work! I particularly appreciate the friendly and instructive error messages is generates. This validator will be quite helpful and instructive to those who do not understand (or simply don’t have the patience for) the mostly vague and loosely worded documentation. Being valid RSS does not guarantee that a feed’s content is well-formed enough to be useful to an end user.

Related link: http://www.intertwingly.net/blog/923.html

This desceptively simple question has different answers in C, Java, Perl, Python, and Smalltalk. Care to take a guess? Once you are done, click on the URL above to see other’s comments, and perhaps share your own.

While I admire Opera Software’s work and persistence in advancing browser design, I can’t help but roll my eyes reading their recent announcement. Opera has developed a mobile browsing technology that has, as Paul Festa reports, “finally solved the long-standing problem of reading big, bulky Web pages on tiny cell phone screens, posing a potential threat to both WAP and to Microsoft.”

Mobile users don’t browse like they do from their desks, so let’s stop trying to repurpose content designed for the Web.

WAP has failed for a host of reasons including the inherent security hole of the WAP gateway architecture, initial deployment on circuit-switched networks as opposed to always-on packet-switched data networks, and a lack of well-designed and useful applications. Even once addressed, browsing would still have its issues and limitations in the mobile arena. Mobile users are "on the go" and generally not in environments where they have the time or patience to navigate content as they would seated at their desks. Their environment requires useful content and applications to be location-based, time sensitive and concise. In addition, utilizing an architecture where nearly all the data and logic resides on a remote server is a poor fit with the reality of unreliable and low bandwidth connections. It frustrates users and erodes their confidence.

Besides, WAP and more specifically WML (WAP’s markup display language) is becoming more symbiotic with the Web. WML2 is an extension of XHTML that utilizes a mobile specific profile. (In his CNET article, Fiesta incorrectly compares WAP and HTML that is apples and oranges. WAP and Web Architecture or WML and HTML would have been more appropriate.)

I’ve always been skeptical when it comes to these attempts to repurpose web content on a mobile device as Opera’s proposal or existing implementations such as Danger’s HipTop browser. I’ve never seen them succeed at anything but frustrating users.

Web pages are designed for large high-resolution color displays, the use of keyboard and mouse and a reliable and relatively high bandwidth connection. Being a display language HTML is not terribly efficient or reliable for consumption by another application. "Qualified guessing" will yield the equivalent of a Frankenstein monster. It’s a hack at best.

Yes, if designed properly a Web page will scale gracefully and adapt to different displays and resolutions — IF is the operative word though. Like eating your vegetables, most of know we should do it, but don’t. Face it, web sites do some rather freaky things with HTML. You don’t have to go past the world’s most prominent software company’s site to witness that.

Despite my criticisms in this area, I still believe in the promise of mobile computing. Mobile data devices will eventually surpass the number of desktops. They’re more affordable and the constraints of these devices insist on a simplicity that will assist the mass-market in embracing interactive services.

Repurposing Web content for mobile is not the answer, it’s a hack. Studying mobile users’ needs and tendencies, getting content into easily consumable formats and developing more usable and appropriate mobile applications are the real answers.

What do you think is the answer to mobile computing design?

Sitting down at a chess board, across the table from an opponent, a contract exists. This contract is that a game of chess will take place, and the rules of chess will be followed by both players. The rules, of course, define the constraints of the game; bishops move diagonally, knights in a 2/1 “L” pattern, white moves first, etc.. Should a player mistake the chess pieces for checkers, and attempt to “jump” another piece, or move a rook diagonally, the constraints of the game have been violated, and chess is no longer being played.

Such is the case on the Internet, with application protocols. When one party opens a connection to another party, a contract is in effect; the contract associated with the TCP port to which an application protocol is bound. As an example, port 80 is for the Web, and any protocol used with it is expected to conform to the uniform interface constraint, meaning that any method being invoked is uniformly applicable to all resources. To not do this, is to play checkers with a chess set. And of course, that’s what Web services are doing.

Another way of looking at this is that most Web services proponents refer to application protocols as transport protocols, which is wrong (most of them are transfer protocols), but explains their tunneling-centric mindset, as they are generally not aware that an application layer contract exists when, for example, you telnet to port 80. Because when you have telnetted to port 80, and are sitting there looking at the flashing cursor, you know what methods you can invoke (OPTIONS, GET, etc..). With Web services, if you telnet to port 80, port 25 (SMTP), or any other, you’re ignoring the existing application contract, and instead count on some separate and different WSDL-defined contract, which you don’t know how to find. Let me repeat and rephrase this, for emphasis; WSDL operations are at the same layer as application protocol methods. And again; HTTP GET is an application semantic, the same as “getStockQuote”.

This is the first step towards understanding Web architecture. Well, it was my first step at least.

Thoughts?

MovableType 2.5, the latest version of personal publishing tool that I and thousands of others use to publish their weblogs, was released. Some of the more tasty technical bits reported in the release notes are:

• You can now easily ping blo.gs and other update services that accept pings adhering to the Weblogs.com XML-RPC interface.
• A new "Keywords/Metadata" field has been added… (I’ve already updated my mt-meta plugin.)
• Added optional TrackBack auto-discovery, which can automatically find TrackBack ping URLs based on permalinks in entry bodies.
• TrackBack pings are now sent using HTTP POST instead of HTTP GET. (In other words it’s now more RESTful.)

This also marks the one-year birthday of MovableType. The dynamic duo of Ben and Mena Trott reflect on the past year here.

Great job Ben and Mena. A tremendous accomplishment for a "a hobby, a way to occupy time previously filled by, well, employment." Thanks for sharing and congratulations! I’m looking forward to what the next year will bring.

Related link: http://kerneltrap.org/node.php?id=444

A new argument has blown up around the license for free use of BitKeeper, the version control system popular with Linus Torvalds and other Linux kernel hackers.

One clause appears to prevent free use if you develop
competing revision control software: this, presumably, would include contribution to the CVS or Subversion open source projects. You would however be entitled to use the BitKeeper software if you paid for it.

Opinion seems polarized: it’s either no big deal, or a big sin against the free software movement. Read the discussion over at KernelTrap.

The story in quick links:

• Larry McVoy of BitKeeper tells Ben Collins he can’t use the free version
• Branden Robinson tells the Debian project that some of its developers may be vulnerable to this clause in the license.
• Reaction
  and comment on Slashdot

Comment on this item in the forum.

alt="GNOME 2 using FreeSans" border="1" />

Good-looking fonts on Linux are one of the most difficult things
to get right. Many Linux desktops are left looking
pretty chunky and spidery when compared to Mac OS X or Win XP
for font rendering.

Recently, the Render and Truetype extensions to XFree86
and the support
for antialiased fonts in GNOME and KDE have brought a hopeful
end in sight. Many users however, are forced to use the fonts
that came with their (unused, of course) Windows CD, or the
redistributable but non-free Microsoft Core Fonts.
Not ideal from the perspective of free software.

Happily, this situation is changing. I recently came across
the Free UCS Outline Fonts
project, which aims at producing a set of free outline fonts covering the
ISO 10646/Unicode Universal Character Set. Installing them
via the ttf-freefont package on my Debian GNU/Linux
system, I was impressed by the quality of the typefaces:
including a monospaced, sans and
serifed font.

Even more impressive is the commitment to the
Unicode character set: the aim of the project is to cover
not only the most familiar Latin character sets but also
Korean, Arabic, Hebrew, Armenina, Georgian, Ethiopian, Thai,
Japanese and more. Combined with the native Unicode support
of GNOME 2, this sounds very promising for the future of
internationalized user interfaces on Linux.

The screenshot on this page shows my GNOME 2 desktop using the FreeSans
font. In fact, this font is about the only one on Linux I’ve found
that offers a similar feel to the sans font used on Mac OS X. Congratulations
and thanks to Primoz Peterlin for his work on these fonts!

Share your tips for good looking Linux fonts here.

In his content syndication weblog, Ben Hammersley points out a nifty mobile application named PeekAndPick that he’s begun using on his new Java enabled phone. PeekAndPick is a J2ME MIDP application for reading headlines and excerpts from RSS feeds and selecting the items you are interested in reading later. Your selections can be compiled into a list of links and emailed to your desktop for later reading.

PeekAndPick, the work of Jonathan Knudsen, is a brilliant mobile app because it illustrates good mobile application design. It doesn’t try to do too much or be like a desktop application. It does demonstrates how mobile and traditional Internet channels can be used to provide a useful and appropriate solution together — though it could do that a bit better. (More on that in a bit.)

The application’s design acknowledges that mobile means "on the move." This mobility generally finds the end user in a less then ideal setting (context) that requires information be concise and interactions simple in order to be useful. Mobile users do not browse — especially on a screen that typically is not much large then a postage stamp. (Note to telcos and device manufacturers: Web content was not designed or with a mobile devices or users in mind. It futile to try because it really doesn’t work out and it just annoys people.)

While very well done application that we have to give Jonathan a great deal of credit for, PeekAndPick is not without its issues or room for improvement.

PeekAndPick underlines the need for RSS feed publishers to exercise good form and provide descriptive titles and concise well-formed excerpts. Since quite often this is not the case, PeekAndPick would probably benefit from a server-side proxy that retrieves feeds, cleanses them and strips any extraneous information that the app does not need. Besides heading off trouble this approach also helps keep bandwidth use to a minimum. Optimizing bandwidth usage not only improves response time, but it saves the end user some money. Remember mobile data services are typically priced by the bandwidth consumed.

Most of the configuration for the app, such as defining your list of feeds, should be handled through a web interface and not the mobile device. At a former employer, where I consulted on a number of mobile projects, we professed "configure while seated, consume while mobile." Who wants to type in a URI like http://www.mplode.com/tima/xml/index.xml with their phone’s keypad?

In my cursory review of the code, the application does not queue messages if a connection if not available. Given the unreliable nature of mobile networks, handling these occurrences is important, even crucial, to developing user-friendly and reliable mobile applications.

I could really use PeekAndPick myself because I find myself woefully behind when I’m away from my desk for any extended period of time. Alas, I cannot use it because I use a Blackberry 957 that is not Java-enabled. (I love my Blackberry and still find it useful, but I’ve been deeply disappointed that RIM has forsaken users and not continued to advance this model’s capabilities by providing J2ME support as its descendants. I suppose that’s for another posts though.)

Check out PeekAndPick and consider your mobile application future.

Related link: http://www.guardian.co.uk/online/story/0,3605,803023,00.html

What happens when the fastest connection you can get is 10Kbps, and no one will install DSL?

Do as they do in my article in today’s Guardian and build a wifi network to cover an entire valley. 10,000 people. 10Mbps. £10 a month.

Related link: http://www.adtmag.com/print.asp?id=6807

Uche Ogbuji, a key developer of the 4Suite platform for XML and RDF processing, has some powerful yet calming advice for working with markup and taking advantage of loose coupling.