In a recent CNET article, Margaret Kane reports on Google and Amazon's success with Web services and the benefits they are beginning to reap. Tim O'Reilly provides his commentary on the piece here. O'Reilly notes a key takeaway from Amazon and Google’s success is "…the importance of a decentralized approach rather than a top-down approach by a single vendor." In addition to his comments, I think it's also interesting to note that two service providers are driving real Web service adoption and not software vendors such as Microsoft and IBM. (Could this be an indication of a significant shift in the industry?)

Being a developer I want to see more service providers support general use Web services. I've been pondering this for a while, but the recent CNET article and the attention it has received put my thinking into high gear. Here are some of the service providers that I would like to see follow Google and Amazon's lead:

• eBay. As the CNET article indicates, eBay has begun down this path on a limited basis presumably with third-party add-on service providers like AuctionWatch. eBay needs to open it up for general use. Some of the obvious uses include more powerful search and monitoring agents (think of melding a news aggregator with "real time" auction information) and "PowerSellers" integrating their eBay activity into their own web sites. This would only be the beginning. As Amazon and Google have proved, the net will find new and inventive uses for services that the original providers never could have imagined. I am just as curious to see what changes in eBay's auction policy may occur from the availability of this new capability.
• PayPal. I realize they are now an eBay company, but since their integration has only just begun, I chose to highlight them separately. PayPal's signature service would be trickier to implement then others because real money is being handled, but it's not impossible. PayPal already offers "convenient" HTML interfaces to payments and shopping carts functionality. PayPal has been a major contributor to making e-commerce transaction possible to the masses. A move towards Web services would be the next logical step in my opinion.
• FedEx. UPS. While keeping with the e-commerce theme, I'll mention FedEx and UPS here. I don’t think general Web service availability would be nearly as earth shaking as all the other examples here. They would be useful to the burgeoning market of mom and pop e-commerce that eBay and PayPal have helped foster. Like PayPal, both offer HTML interfaces to some of their services that can be made machine readable with some screen scraping which can be problematic and brittle. In addition to package tracking, both companies should create APIs for managing their shipping contacts, calculating costs relative to weight and location, and subscribing to package delivery alerts.
• MapQuest. Opening their geographic plotting engine and roadmap data could yield some very interesting applications. An obvious use would be integrating directions with traffic advisories. (Call me odd, but I find it helpful to know that "fastest route" has two lanes closed for construction.) I had once hoped Vicinity/MapBlast would have made a move into Web services to gain ground and push MapQuest, but now as a Microsoft company that hope has waned given Redmond's top down approach to Web services.
• Yahoo. The Web portal company has been marketing premium services to generate new revenue streams. Yahoo's relative success, in addition to Apple's similar foray with their .Mac services, indicates that there probably is a market. I believe the availability of a Web service API would be helpful to furthering those efforts. Yahoo Stores would benefit immediately from such a move. (See my comments on PayPal.) Yahoo Groups can be accessed in part using email and to retrieve recent messages as an RSS feed, but further accessibility via Web services could be useful. Other potential targets for Web services would include interfaces to personal email, calendar, briefcase and address book. (I would pay a nominal fee to Yahoo for this.)
• Any site with information and news lacking RSS support. Whether it is just assumed or simply overlooked, RSS is the most widely deployed Web service across the Internet. Granted, most RSS feeds have very simple interfaces with almost as simple backends that are unlike the Web services that usually come to mind. (Who says Web services need to be complex or sophisticated anyhow?) Under the principles of the REST architectural style that the Web was built on, RSS feeds do qualify. Consider that any site search engine becomes a Web service if it could emit results in RSS and the format's potential in the realm of Web services becomes more apparent.

This is by no means a complete list. It is however a starting point to further discussions as to the future of Web service adoption and their potential of Web services to help drive innovation. What do you think?

What Web services would you like to see?

I’m very happy with my iMac, but I’ve been working with various PDAs and have to admit some lust for the Tablet PC stuff I’ve seen lately, since clamshell laptops (like the one I’m working on at the moment) just don’t really inspire me. Since the holidays are coming soon, writing to Santa seems like a good idea…

I think Apple already has the software I want - OS X and Inkwell pretty much promise to take care of my needs. Excellent network support, a Unix foundation, good (and improving) Java support, and a friendly interface - very cool.

What I’d like is a new piece of hardware. The size and weight of the iBook are fine with me, but I want less. Take off the keyboard and put a touchscreen over the LCD. Let me use the LCD either horizontally or vertically, and let me plug in a USB keyboard or mouse if I need them. Give me a folding stand that lets me set it up on a hotel desk in landscape or portrait modes (I’ve wanted a portrait-oriented monitor for my Mac since about 1989), plus a VGA output for conference presentations, and I’ll be set.

A weatherproof cover for outdoors would be a nice option, but doesn’t have to come in the main package. iBook prices would be nice too…

Anyone else want a bit more flexibility than a clamshell laptop?

The SOAPAction header in SOAP 1.1 has given many developers and implementors fits about understanding its purpose. I suggest that this is because of the two very different ways in which SOAP can be used, and that SOAPAction exists primarily to support the use that few are making of SOAP, which IMO, is the more valuable of the uses.

The SOAP 1.1 specification says this about the HTTP SOAPAction header;

The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request.

The presence and content of the SOAPAction header field can be used by servers such as firewalls to appropriately filter SOAP request messages in HTTP. The header field value of empty string (”") means that the intent of the SOAP message is provided by the HTTP Request-URI. No value means that there is no indication of the intent of the message.

The ambiguity is principally over the word “intent”. The definition of the related word “intention” seems fairly straightforward;

a determination to act in a certain way

So if you’ve got a SOAP message, like this one from the spec;

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body>
       <m:GetLastTradePrice xmlns:m="Some-URI">
           <symbol>DIS</symbol>
       </m:GetLastTradePrice>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Then clearly the intent/intention of the message being sent is the meaning of “GetLastTradePrice”. Given this use of SOAP (with the method in the SOAP envelope), it should not be surprising at all that developers are confused, as it appears as though the value of SOAPAction is redundant.

However, there is another use of SOAP that can be made that demonstrates the value of SOAPAction. This use involves not putting the method name in the SOAP envelope, and instead using the method of the underlying application protocol (which is most commonly ignored by Web services). In the case of HTTP that means using the POST method.

HTTP POST means “accept as a subordinate”, in the same way that adding a Java AWT component to a container does, as does the real world action of posting a letter into a mailbox. The end result - what state change occurs as a result of this operation - is unknown to the sender, except that upon receipt of a 2xx response code, they know that it was accepted. This is analogous to knowing that that a textfield was added to your container, but not knowing about how that operation changed the state of the container itself (such as its layout).

Now, using the AWT component/container example again, consider that there can be different types of containers, such as Panel, Box, Window, etc.. Sometimes, it’s meaningful to the user of that container to know that’s it’s more than a generic container, and that it is indeed a Box. It’s the same as the difference between these two code snippets;

    comp = new TextField( "test" );
    java.awt.Container c = Foo.bar();
    c.add( comp );

and

    comp = new TextField( "test" );
    java.awt.Container c = Foo.bar();
    ((java.awt.Panel)c).add( comp );

The difference is one of expectations. “add()” has the same base meaning in both cases, but in the second case it has the extended meaning/intent of “add as a Panel”. If the container is not a Panel, an exception is thrown so that the client knows this expectation cannot be met.

HTTP POST means basically the same thing as “add()” in that example, which provides a hint about how SOAPAction can be used; the value of the SOAPAction header should be a URI identifying the “extended intent”, namely the type of the container that the sender of the SOAP/HTTP message expects to be dealing with. If the expectation cannot be met, a fault should be generated.

Note; in SOAP 1.2, the SOAPAction header has been replaced with the “action” attribute on the application/soap+xml media type. But it works almost exactly the same way as SOAPAction.

UPDATE; it turns out that the behaviour of SOAPAction isn’t as I described with respect to the expected “type mismatch” fault. I consider this a bug in the specification of SOAPAction/action. Unfortunately, it’s not one that can be easily patched because this is extended behaviour that existing SOAP agents/libraries don’t know about and can’t support.

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

Andrew Watt wrote to xml-dev asking “What are the strongest arguments for continuing development of XHTML 2.0?”. Keeping the Web alive seems the most important to me.

This was my reply, mildly edited to free it from the xml-dev context:

—————————

[Note that all statements about corporate or consortium behavior are based on sheer Kremlinology, and may not in fact represent the way those organizations see their own behavior. I’m sure many people here will disagree with that perspective.]

XHTML 2.0 feels like a crucial ingredient of the browser conversation to me. That conversation has pretty much stalled over the last few years. Why?

Netscape has vaporized into AOL, an organization that hasn’t exactly loved the Web, and while Mozilla is perhaps the torch-bearer par excellence for the ‘traditional Web’, it lacks the "installed with everything" advantage.

Microsoft appears to have lost interest in Internet Explorer since "winning" the Browser Wars. The upgrades to IE appear to be largely outside the browser engine, and improvements are clearly incremental. In
a lot of ways, it feels like the last major change to IE was in IE4, when they rebuilt the object model - and bonded it tightly to HTML.

There are other companies and projects in the browser space, and I’m quite fond of Opera, but I don’t see great hope for a new browser reinvigorating the overall market.

Meanwhile, the W3C as an organization appears to have lost interest in HTML. The leadership appears distracted by RDF and (to a lesser extent) XML, while the membership appears distracted by Web Services, a tool kit with only remote connections to its supposed "Web" origins. The HTML WG seems to spend a lot of time fending off other parts of the W3C who think they know better than mere HTML culture can produce.

The HTML WG seems to have suffered a cursed existence for the past few years. Namespaces were supposedly going to help us integrate other XML vocabularies (SVG, SMIL, MathML, etc.) but proved a huge nuisance for XHTML’s three-forms-one-vocabulary approach. XML 1.0 DTDs might have
been all right for XHTML modularization, but wow the namespace interactions were awful. W3C XML Schema didn’t help that front much either, as the backers of RELAX NG have been happy to demonstrate.

Given all of that, the sheer perseverance of the HTML WG deserves applause. <pause />

Despite that perseverance, the forward development of HTML has suffered about the same lack of momentum that Mozilla has suffered. Delays caused by internalizing these externally-inflicted issues and a general drift away from HTML as the central activity at the W3C pretty much mean
that the "traditional Web" with its HTML and browser-based foundations
is in trouble.

There have been a few nice pieces of work to come out of the XHTML Working Group in that period (XHTML Basic is a favorite of mine), but it’s only fairly recently (last six months?) that I’ve really begun to see XHTML discussion on Web developers mailing lists. (XHTML-L doesn’t count for that, though its membership has grown slightly.)

XHTML 2.0 is an opportunity to break out of the stall. I see XForms in particular as crucial to keeping the Web from being eaten by the Web Services and "Rich Internet Applications" that have been eating around
its edges for a while. The Web has to move forward if it hopes to survive, as its promise of cheap interoperability (which it did remarkably well, even with the Browser Wars) is under assault once more from vendors who have a lot to gain by fragmenting the Web and Web applications into proprietary pieces under their control.

XForms is especially critical because it addresses probably the weakest part of the HTML infrastructure. Forms have sort of barely evolved since their first appearance, and they’re pretty much a nuisance.
They’re one of the few places where I find information validation genuinely powerful, and current solutions on both the server and the client are pretty ugly. XHTML 2.0 looks overall like an effort to make XHTML a cleaner environment in which to work, and that seems worth
pursuing as a first step toward putting XHTML back on the tracks.

While it’s not at all clear that Microsoft or the other browser vendors have the time or interest in improving the Web, the only way forward seems to be to try, and (X)HTML appears to be the right place to do it. It has a wide base, a lot of committed developers who have been starved for features over the past few years, and foundations that are both well-understood and reasonably extensible.

Will XHTML 2.0 sweep the world? It’s too soon to tell. Is XHTML 2.0 worth the effort? I think the answer to that is an obvious yes, and not because XHTML needs all the latest XML gimmicks. The Web needs some progress in XHTML for the to stay alive. I worry that at current rates of progress the Web will have disappeared by the time the Semantic Web is ready.

Is the Web fading? Can XHTML 2.0 help?

I’m don’t tend to use RDF in my own work, but I’m getting very concerned that recent blasting on RDF risks obscuring a lot of things that RDF does very well.

The work I do with XML and markup really depends on the creation of markup vocabularies that at are least human-approachable if not automatically intuitive. I don’t expect customers of my projects to understand the code that drives them, but I do expect them to have a decent chance of understanding the data formats that I use underneath those projects. Given that set of priorities, XML generally makes more sense to me than RDF, as explicitly embedded markup produces labeled structures that are directly visible in the document. Cool stuff, I think.

I actively resist and frequently blast technical changes to XML which threaten XML’s basic approachability. Sometimes those proposed changes have RDF roots - Namespaces in XML has been an endless source of URI-induced misery, and I can’t say I’m fond of Liam Quin’s RDF-based “thought experiment” for XML/R. RDF is far from the only problem, however, as W3C XML Schema and XQuery both demonstrate that complexity is alive and well in sectors where RDF is barely a concern.

RDF is excellent at addressing a particular set of problems. The Resource Description Framework’s primary approach is description. XML often presents something (a document, a table) directly; RDF more typically presents a description of something, not the thing itself. For some appications - like metadata and ontology development - this approach fits beautifully with the problem set.

RDF also seems to do its best work when it can be presented in some form other than XML markup. RDF’s graph approach and XML’s hierarchical approach are very different. While I’m not fond of being handed a dozen marked-up triples and forced to sort them out, RDF descriptions often make beautiful sense when presented as diagrams or exposed through APIs.

If RDF fits your problem set, run with it. If it doesn’t fit, fight it - for that problem set. We’re not all going to be happy all of the time, but RDF’s strengths should not be forgotten in the arguing.

Is RDF working for your projects? Why? Why not?

"What puzzles and confuses me is why there is so much animosity towards RDF" writes Shelley Powers, author of O’Reilly’s upcoming book on RDF.

Shelley’s post was made in response to Tim Bray’s attempt to implement an RDF model into the RDDL specification that ultimately lead to his recommendation to use XLink instead. Bray’s comments where picked up through the community unleashing a torrent of criticism and "animosity" directed at RDF. Jonathan Borden summarizes the significance of Bray’s comments when he wrote, "this is the crux of the problem. If Tim Bray can’t do RDDL/RDF using his little toe, with his hand tied behind his back and the rest of him hog tied and upside down, then what prayer to we have trying to foist this upon the rest of the world, i.e. people who just want to create and document XML namespaces?"

Shelley Powers’ post to the xml-dev touched off a heated discussion late last week that continued across mailing lists and weblogs through the weekend. In this weblog post I will attempt to highlight and summarize this conversation. I attempted to order the comments in a way that they make sense and do follow somewhat of a chronological order though not entirely. I have attempted to compensate for the distributed and parallel nature of the conversation in order to maintain some semblance of its flow.

"I am particularly unhappy because of Tim Bray’s involvement in all of this," wrote Shelley Powers on her weblog. "There’s an implication and an assumption made that because Tim Bray ‘invented’ XML, he’s qualified to be a definitive judge of RDF and RDF/XML. However, the two efforts are not the same: XML deals with meta-language, RDF with meta-data. Tim has a right to his opinion, and I don’t fault him for it though I don’t have a tremendous amount of respect for his half-hearted and rather dubious effort to use RDF/XML to model RDDL."

(Jonathan Bowen subsequently posted a human-readable RDF compliant RDDL format to demonstrate a human readable RDDL format could be created with an RDF model.)

Shelley offered some advice to anyone put off by RDF: "If you don’t understand it, and don’t want to take the time to understand it, or don’t feel it will buy you anything, or hate the acronym, or you’re in a general bitchy mood that’s easily triggered if someone uses "Semantic" in the same sentence that contains "Web", the solution is simple: don’t use it. Don’t use it. Don’t study it, look at it, listen about it, work with it, sleep with it, or generally go out and dance late at night with it."

She also notes "However, you may feel about RDF, the spec, or RDF/XML, the serialization, I would hope that you all remember one thing: in the last few days, the RDF Working Group has released not one, not two, but six new working drafts. Six. That’s a hell of a lot of work."

(See this post for more on these latest RDF drafts from the W3C’s Semantic Web Activity.)

Simon St. Laurent writes "I have a lot of respect for certain RDF applications that appear to be working, a general lack of interest in describing the world as graphs, and a serious distaste for RDF syntax. I genuinely resent what I see as the unfortunate influence of RDF on XML’s post-1.0 development and the URI-centric viewpoint it has foisted on XML."

Simon later went on to say "RDF is powerful stuff, great for those who want to use it. Just keep it off _my_ dance floor, please."

Tim Bray responded "I’d go further. I think the current RDF/XML syntax is so B.A.D. (broken as designed) that it has seriously got in the way of people being open-minded about RDF. I’m baffled why the RDF working group has been forbidden to work on replacing that syntax."

In response Shelley Powers posted "because, Tim, there are implementations of RDF/XML as described, including Mozilla and RSS 1.0. I know you don’t approve of them, but they are real, they are production, they are in use. Bitch about them as much as you want, but people use them."

On the comment board to Shelley’s weblog Mark Pilgrim offered his take. "The fundamental flaw of the overzealous RDF advocates is the implicit assumption that "because I want to work with this data as RDF, it must be produced and stored natively as RDF." This is demonstrably false, and is what people are objecting to when they talk about "the RDF tax"."

Joe Gregorio published similar sentiments, "…my animosity comes from a push by possibly overzealous RDF proponents to change every format they come in contact with into valid RDF serialized as XML. I can point to RSS 1.0 and now the abortive RDDL as RDF attempt as failures of that strategy. On the other hand I can point to the use of RDF in Mozilla as a successful strategy of *leaving the native format alone* but still getting the benefits of RDF, as I pointed out Wednesday."

(Gregorio later published that Mozilla’s use of RDF is smaller then first believed according to a OSAF mailing list thread.)

Gregorio continues, "I think a healthy dose of skepticism and a critical eye turned on it by people outside of the usual circle would be helpful to RDF, and it certainly couldn’t hurt the XML serialization."

Elsewhere Tim Bray offered: "<famous-anecdote>Stuart Feldman, the Bell Labs guy who invented "make", woke up one morning a few weeks after he’d released it, and realized that the syntax basically sucked - all those tabs and colons and weird continuation rules. He started working on something better and was shot down because someone said "Stuart, there are *dozens* of people using this, it’s too late to change it."</famous-anecdote> I think the number of people who are now using RDF is comparable, in relation to the number of people who need something like RDF, to the couple of dozen make users in 1970-something. It is *not* too late to fix the RDF syntax, it just takes some courage and initiative."

Shelley Powers responded:

"Yeah, but who is to say that [Stuart Feldman’s] new approach would have been better? We can work and work and work a spec until we’re blue in the face and not find a perfect solution. People learn to work the situation, or they learn to automate it — i.e. autoconf, automake, and libtool.

Tim, we need the [workgroup] to finish. We have been waiting over a year for them to finish. We need something stable that we can work with. We do NOT need to start all over again. I would pack it in at that point. I really would."

Responding to a comparison of RDF now to HTML in the early days of the Web, Bray wrote, "HTML was by no means "bad". It was exactly what the world needed, and millions of people started using it because they liked it and because they could do "view source" and figure it out. My gripe with RDF/XML is precisely that it’s failing to learn this lesson from HTML’s success. Thus not enough people are using it, even though it’s arguably what they need."

Shelley Powers notes, "the RDF Working Group was given a charter not to rewrite RDF/XML but to answer issues and provide as much cleanup and clarification as they could but to still remain within that support for previous implementations. It’s sad that one can’t just throw things out and start over again, but that’s the way of the real world."

To that Bray responds "No it’s not and yes you can, and you should."

Elsewhere Mark Pilgrim wrote in response to similar comments by Shelley, "you’re hurting yourself more than anyone else by defending the status quo. You have a lot invested in RDF (the theory), and it’ll all go to hell. The rest of the world will remain blissfully unaware that there was this great idea here, buried under mounds and mounds of incomprehensible angle brackets."

Tim Bray also wrote "The proponents of RDF (including myself) say that RDF’s value add is that it allows the efficient interchange and manipulation of [Resource, Property, Value] triples. I happen to believe this propaganda and I also believe that one of the obstacles is the human-incomprehensible syntax. If you believe that RDF/XML’s current syntax is not a problem please continue with your project of trying to sell it to the world, but it feels to me you’re trying to accomplish a good thing with one hand tied behind your back."

(Mark Pilgrim offers a personal account of his attempts and frustrations with RDF here. I don’t quote it here since the entire post is worth a read as a first-hand account of the issues being discussed throughout this discussion.)

In addressing the XML serialization of RDF Danny Ayers offers, "probably the primary cause of the ugliness of RDF/XML is the mismatch between the tree model of XML and the graph model of RDF. To explicitly represent a graph in XML the syntax will start getting ugly whatever you do. This is a weakness of XML, not RDF.

In a post to the xml-dev mailing list Shelley Powers wrote "I’ll be honest, I don’t care about the human readable/writeable aspects of RDF/XML as much as I do care that there are tools and APIs that manage it all for me. Sorry — but I just don’t think that is the most important aspect of either XML or RDF/XML. Again, IMHO."

To which Sean McGrath replied:

"I’m afraid, I take a diametrically opposite view. Things should be as complex as necessary but not more complex.

Punting to tools and APIs to salvage mankind from complexity of its own making is one of the main reason this industry is constantly battling the alligators rather than clearing out the swamps."

Elsewhere Jack William Bell echoed the same sentiment. "I have a problem with [an (easily) human readable format not being necessary]. If you don’t care about being able to read it easily, why not use a binary format of some kind in the first place and reduce the bandwidth footprint?"

Tim Brays writes "I guess where Shelley and I would agree to disagree is that she doesn’t think that easy human-readability is very important in the data formats she uses, and I think it’s terribly, terribly important; I think one of the central lessons of the Web is that enabling people to do a "View Source" and roll their own based on what they see is, well… there’s nothing more important."

Shelly Powers explained "RDF/XML is a mapping of that model to XML — a mapping that’s not necessarily easy or uncomplicated. XML was picked because XML is the prime metalanguage format used in many intra-mechanical transitions, such as forming the messages and providing the framework for something such as SOAP. It wasn’t necessarily picked because XML is human readable, though we hope that would be a side benefit."

Tim Bray writes:

"for the record, I did *not* invent XML, I was a member of a [workgroup] of 11 people supported by an interest group of another hundred or so who subsetted an existing standard called SGML whose position was spookily similar to where RDF is today: it’s important, some smart people are using it to do some big things, but it has no grass-roots uptake.

Turns out that some of the things you could do with SGML you can’t do with XML, and some of them are awfully handy, but in the end it turned out that the complexity cost for doing them pushed the cost/benefit ratio into really lousy territory. Hmm, there’s an echo in here."

In response to a post on why RDF is hard, Simon St. Laurent wrote "I don’t think the RDF community has ever really understood that what they do is genuinely difficult for most people. The RDF community seems very self-selecting to me - those who can cope with RDF like it, and the rest of us keep our distance. I’m not sure it’s ever been clear to people who find RDF intuitive why so many people bounce off of it completely, and I’m not convinced that it’s possible to explain that to someone who genuinely likes RDF."

Shelley Powers replied "No one is forcing anyone to use RDF. This isn’t a dismissal — this was meant to be a reassurance."

What’s wrong with RDF and its XML serialization?

Related link: http://bugzilla.mozilla.org/show_bug.cgi?id=97806

In both Open Source and Commercial circles, the XForms Standard is building momentum, as shown by comments in the Bugzilla database.

The XForms standard just crossed from myth into reality with the publication of the Candidate Recommendation edition at the W3C, along with a call for implementations.

This transition led to comments on the Bugzilla page request to implement XForms in Mozilla:

Well, XForms is now a Candidate recommendation … will we wait until Microsoft starts deploying XForms, and then we have to play catch up?

In response, one poster wrote:

I work at one of the largest pharmaceutical companies in the world, and we need XForms….(Most importantly) To get rid of the Javascript dependancy. Javascript accounts for 90% of our headaches in complex forms, and is extremely brittle and unmaintainable.

Later in the same day, John Keiser, of AOL/Netscape, added:

I’ll take this. I will start implementing a month or two from now… It should be a fairly simple task to get a basic implementation up

In the meantime, both commercial and open source outfits have stepped forward with running code: Novell announced, a complete XForms implementation, not to mention fully operational code from X-Smiles, Mozquito, e-XMLMedia, FormsPlayer, and a great phone implementation by HandWise.

What you can do:

As always, you can contribute to the continued success of XForms. You can vote for it in Bugzilla (visit the main page and click “vote for this bug”; registration required). As of this writing, XForms ranks in the top 5, with 171 votes.

Of course, if you can code, there’s plenty of opportunities: XBL & JavaScript for Mozilla; Perl for a server-side validator; Python for a couple of interesting projects.

Share your thoughts below…

Share your comments and experiences with XForms here:

Related link: http://www.frankston.com/public/writing.asp?item=Essays/Teething.html

In response to the Bluetooth article "Teething Pains" published by the Boston Globe on November 11th, Bob Frankston provides some notable insights and criticism of the wireless networking technology’s design.

We should learn from the example of X.400. X.400 was (is?) a mail protocol approved and required by essentially all the telecommunication agencies throughout the world. It was designed over a period of ten years yet failed against SMTP (Simple Mail Transport Protocol) which could be implemented in an afternoon. Like x.400, the Bluetooth was designed and promulgated before anyone could learn from the first generation. Bluetooth is designed to work in the specific cases imagined by its designers and thus will perform very well in precisely those scenarios and these are the scenarios touted in press releases.

Frankston continues…

Bluetooth is in the mainstream of the old model of telecommunications in which all the services are defined by the center and every new capability must be approved before it can be deployed and thus before we even understand it. 802.11 is simply a transport for packets and doesn’t stand in the way of creating new capabilities.

Once again we face a familiar paradox. Bluetooth which defines so much of the solution is thus limited to what it defines and that is very little and it only works among a few nearby devices. 802.11 which makes few promises inherits the existing richness of the Internet Protocols and has no such limits of distance.

What are your thoughts and experiences with Bluetooth?

Related link: http://www.havahart.com/nuisance/cageproduct.htm

A tiny squirrel seems to have taken up residence in my livingroom, and I just set a Havahart trap to catch it. While I was baiting the trap with peanut butter and tasty nuts, and wondering where I would release the poor confused animal, I was pondering another discussion about how companies listen to their customers to stay in business.

Listening to your customers is generally considered a good approach to conducting business. There’s the classic line about “Markets are conversations“, and companies that don’t know what their customers want aren’t likely to have very many customers for long - it’s a classic and sometimes even sad story.

Listening to customers doesn’t necessarily equate to giving customers what they want, however. When an organization intent on making a profit is listening to customers, it’s often looking for things that will attract customers but which also provide them with a means of controlling those customers, in particular their spending habits. Using features as lures for product lock-in is a pretty common approach, as is ignoring requests for features that set customers free.

As I was baiting the squirrel trap, I had a specific customer in mind, one I even kind of like watching. I don’t plan to kill the customer - this isn’t that kind of trap - but I certainly plan to put the squirrel into a cage where I can control his actions for my benefit. My benefit, a squirrel-free house where my food is safe and my dogs aren’t barking all the time, is the squirrel’s cost, as he won’t get to enjoy the free food, heat, and largely predator-free environment inside the walls of my house. I’m certainly hoping to have a conversation with the squirrel, but one in which I benefit and he pretty much loses.

Businesses have much more complicated dynamics than squirrel traps, and human customers tend to be a little bit pickier (we hope) than my friendly squirrel. That’s a lot of why I’m interested to see some notoriously controlling companies opening up a bit with open XML formats. Apple is using bits of XML throughout its OS X infrastructure, and developers who know where to look can use that XML to make changes directly to various systems. Microsoft also appears to be opening up its Office applications with XML formats.

Openness is risky. Giving customers genuine choices, including the choice to reuse their information elsewhere, means providing features without laying a trap. That’s pretty impressive stuff, perhaps even community service. Or is the trap just larger, its gates further out of sight?

Have tasty features ever locked you in a proprietary cage? Do you worry about open features leading to new kinds of proprietary cages?

Related link: http://www.wired.com/news/medtech/0,1286,56223,00.html

Now, cool scientists can carry not only tunes, but the entire human genome sequence on their iPod.

A researcher at the Hubbard Center for Genome Studies, tired of waiting for slow file transfers, instead uses his iPod to store and transfer the humane genome. In addition, Apple and Genentech developed an optimized version of BLAST (basic local alignment search tool) which can process 200,000 base pairs in 20 seconds.

I’m starting to work on the 2nd edition of Java Web Services, and I’m wondering what to do with the UDDI chapter. Does anyone out there actually use UDDI, or have plans to? I haven’t heard much noise about it in a while…either from industry buzz or from customers for that matter….

I’m thinking about putting it more towards the back of the book, or maybe even getting rid of it as a separate chapter. What’s your view on the subject?

I’m looking for feedback from the readership. Please respond.

Related link: http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&w=2

In a recent posting to the Apache Axis dev list, we (Sonic)
outlined a proposal for creating a JMS URL syntax to be used by the Axis client
to pass JMS information down to the JMS transport layer in Axis.� This URL syntax allows an application client
to specify things like JMS ConnectionFactory location, Queues and Topics, etc.

This is part of an ongoing project where Sonic Software is
working with some of the core Axis developers to create a JMS transport layer
in Axis as an alternative to HTTP, and to revamp the Axis core engine to enable
true asynchronous style communications.�
For a good backgrounder on the whole effort, there is a pretty decent
writeup at http://www.oetrends.com/cgi-bin/page_display.cgi?109

We are looking for feedback on the proposal.

As always, your comments are welcome.
Dave