Monthly Archives: September 2003

RDF Forms

I’m pleased to announce the release of the first draft of RDF Forms. This is the first usable specification to emerge from some ideas that have been floating around in my head for a couple of years (in various guises). It looks brain-dead simple now, so I think (hope?!) that means that I probably got it right.

As an example of an RDF Form, here’s a query (aka GET) based one for the “Top downloads” service of Mark’s RESTful MS Web services front end;

<rf:Indexable xmlns:rf=""
  <rf:indexedBy rdf:resource="" rf:shortName="topType"/>
  <rf:indexedBy rdf:resource="" rf:shortName="topN"/>
  <rf:indexedBy rdf:resource="" rf:shortName="cultureID"/>

Thanks to Jan Algermissen and Aaron Swartz for their help (though Aaron didn’t know he was helping on this when he answered a question for me 8-).


Greg’s asking for comments on the using a feed URI scheme to identify a subscription action for the feed, e.g. “feed://”.

I think we can do better. Here’s two big reasons why I don’t like this proposal;

  • “Clicking” on a URI should always be safe, and provide information about the identified resource, not take an action upon it. This enables humans and automata to be able to trust that they’re not entering into an obligation by dereferencing a URI (any URI, not just http URIs).
  • The resource really is “”, and putting “feed://” on the front obfuscates that from parties who don’t know what “feed://” means.

So what’s the better proposal? For one, get folks to start using an RSS-specific media type so that the client knows it’s RSS. Then you just need to register your aggregator as the application that handles that media type. Within the aggregator, I would expect to see that feed after clicking on the URI, but with a BIG “SUBSCRIBE” button in plain site when it realizes that I’m not already subscribed to that feed. As a bonus, there’s no need for a different “subscription URI”.

Early April fools

I saw a BEA press release the other day, and was feeling a bit cheeky tonight, so I threw this together. April is just too far away. 8-)

Press Release

BEA embraces the Web for integration
Friday April 1, 2005 6:00 am ET
Regrets role in Web services.  Vows to get down to business to solving
customer integration problems.

SAN JOSE, Calif. -- BEA Systems, Inc., the world's leading application
infrastructure software company, today announced that it was
discontinuing any further support of "Web services", and was announcing
sweeping organizational changes that will better position it to produce
high quality products that enable the creation of services built on the
architectural principles that have made the Web such a success,
including the constraints of the REST architectural style.

"It boggles the mind to realize what a huge mistake had been made with
Web services, and how this awesome integration platform - the Web - was
right under our noses the whole time.", said CTO Scott Dietzen.  "In
retrospect, it's all so obvious, but that's small consolation when you
consider how much time and money we've wasted these past few years".
CEO Alfred Chuang added, "BEA is proud to be the first major application
infrastructure software company to close the book on this dark chapter
of IT history.  We apologize to our existing customers for our role in
this debacle, and look forward to working with them to help put their
services where they belong, on the Web".

The company also announced that David Orchard had accepted the role of
Chief Architect of the newly formed Semantic Web group, whose mission
will be to integrate the W3C's Resource Description Framework into BEA's
products, enabling customers to further simplify data integration tasks.
"That's still XML, right?", Dave was heard to say shortly after learning
of his new assignment.

About BEA

BEA Systems, Inc. is the world's leading application infrastructure
software company, providing the enterprise software foundation for more
than 15,000 customers around the world, including the majority of the
Fortune Global 500. BEA and its WebLogic(R) brand are among the most
trusted names in business.

Headquartered in San Jose, Calif., BEA has 77 offices in 31 countries
and is on the Web at

Bill de hOra on documents and interfaces

Sean points to an old (June) post by Bill on Foundations for component and service models. I’m not sure why I missed this one, but it’s more or less bang on from my POV.

One quick comment …

“Calls should return documents not objects”; if the calls returned the serialized state of objects, would that be ok? Oh, right, documents are serialized object state P-)

Broken record, me?

REST for complex integration?

Radovan Janacek writes;

However, in large scale scenarios, or in complex integration scenarios (many services, complex processes, evolution, independent participants) I definitely vote for REST-based approach.

Awesome. Conventional Web services wisdom has always been – until now – that this kind of scenario is exactly where you need Web services. I look forward to seeing how WASP ends up incorporating his ideas.