Follow Your Nose or Hold Your Nose?

Thank you for giving me the opportunity to address you today. I am honored to be here and hope to make the most of the short time we have together. I will try to keep my remarks succint and hope what I tell you today will spark ideas and promote discussion.

I will only briefly mention the paper which I submitted for this workshop; "Follow Your Nose vs. Hold Your Nose." I ask that you read it, if you haven’t already, and to feel free to provide feedback and comment on it. The paper and this talk are ‘partners’ in my conspiracy not twins. So, I will use the contents of the paper as merely a ‘jumping-off point’ for my presentation today.

To that end, I want to focus on the sub title of the paper "Obserations on the state of service description on the Web." And I want to highlight on three things:

Because these three topics are at the heart of the paper. We should be promoting and enhancing the Web. We need to think clearly about how service descriptions are, or are not, doing just that. And I want to offer up another way to look at both the problem and the potential solution.

It is appropriate to talk about the Web this month because it was 25 years ago that Tim Berners-Lee first began outlining the notion of the WordWidWeb.

It was in 1990 and he and Robert Cailliau (k-eye-you) authored the Proposal that defined the Web that we know today.

Instead of going through the details of that document, I’d like to offer a slightly more whimsical interpretation of the Web.

Play Video

So, two points from the video are worth noting. These are part of what I call the "Disney Dog Rule."

First:

Or, to take a quote from the Berner-Lee/Cailliau proposal:

One of the key aspects of the Web is the notion that, even if the client (browser) and the server have ‘never met’ they should be able to understand each other. They should be able to interact successfully. This was one of key problems Berners-Lee and Cailliau wanted to solve:

And the second part of this rule is:

Dug’s sudden realization that there might be something ‘over there’ that would interest him is also an essential aspect of the Web. Again, to take a related quote from the 1990 document:

"Browse at will" is, if you will, the client view of the "I have just met you…" idea. We can browse at will when servers can be linked together. And linking is incredibly important here.

And, in a more updated version of the same theme, here is a quote from Ed Summers talking about the power of linking data:

The Web is not just a way for A client to talk to A server.

Its about creating a way for lots of clients to talk to lots of servers.

And it is important to keep in mind that it is links that are important here.

Note that the talk here is about links, not URLs. URLs are the way we create and express links.

It is links that make the Web go round. Links are the value in the network, not the content on either end.

This notion of link value, first described by Barabasi and Albert in their 1999 paper "Emergence of Scaling in Random Networks" has come to be known as the Power Law of Scale-Free Networks.

And there is no better example of a Scale-Free network than the World Wide Web.

So, the three things that capture the essence of the Web are:

And that brings me to point #2: Service Description.

Service Descriptions owe most of their legacy to the notion of Ingterface Description Languages or IDL. The classic IDL formats that helped shape the way developers interact with component software includes:

Name them as they build

These are all standards that describe ‘local’ interfaces; interfaces for components that are all running in the same general ‘clock space.’ These appeared before the Web and have none of the characteristics we talked about earlier ("I have just met you…", "Squirrel!", and "Scale-Free".

And there are a series of Web IDLs, too:

And there are many more. As of this talk there are more than a dozen service description languages for the Web either proposed or in active use. And they all have the same legacay: describing ‘local’ interfaces for code-based components.

And, for that reason, they are all broken.

On the Web…

But with Web IDLs…

They rarely support multiple formats and almost always use only HTTP. I will point out that WSDL is a notable exception to this rule.

On the Web…

But with Web IDLs…

Hierarchy is actually the central controlling element in Web IDLs. It the resource list and the outline-like relationship between them upon which most all serbvice descriptions for the Web are based.

Finally, on the Web…

But with Web IDLs…

Client applications are led into memorizing links and workflows such that the same client application is now tightly bound to that single service model.

Service Descriptions for the Web not only don’t support the "Follow your Nose" principle, these formats actually train developers to write clients based on the "Hold your Nose" rule — to ignore what you don’t recognize and go about your business.

To paraphrase a wise sage: "These are not the squirrels you are looking for."

Pause

In fact, service description on the Web today almost always describe this:

Instead of this:

But there may be something else. And that leads to to point #3…

So, if service descriptions on the Web are really broken, what would it take to change that?

What would a "unbroken" service description look like?

and how would it support the three things we covered in the first part of the talk?

So, I am a fan of the notion that..

and service descrptions today are not working — at least not for the Web.

It turns out, service descriptions are providing implementation-specific details. which format to use, which protocol you must support, what data points and workflows are like and so on.

Service descriptions today are describing "The Solution."

Which would be great if everyone’s problem was the same exact size and shape as your solution. But, as we know, that’s not the case at all. Almost every use-case has some unique aspects and it is rare that even people on the same team can agree to the ‘right way’ to solve a problem. Magnify that by the millions of people on the Web who we haven’t met yet and it can be daunting to think we’re all going to love each other as Dug the Disney Dog does.

Luckily there is something else we can more readily agree to — the problem domain. In fact, as software developers and architects, we do this quite often.

We collect information, find the boundaries, and gather the details of the target problem domain. That’s what a good interface description for the Web does: models the problem domain.

And that’s what the Web does, too. It models the way nodes can be linked together and traversed over time. The Web is not a solution, it’s a problem domain where thousands of solutions can (and do) appear.

Stu Charlton alluded to this back in 2007 when he was trying to describe the how re-use works differently on the Web:

Serendipity happens when clients are not tightly bound to a single service. When the Power Law is allowed to take over and lead to unexpected links. When clients can ‘meet’ new servers and successfully interact with them.

pause

Describe the domain without specifying format or protocol. Let clients and server negotiate formats and protocols.

Describe the domain as a set of nodes, not a hierarchy.

Allow each client and server to estalbish their own linking and workflow.

And finally…

Describe the domain as a scale-free network.

Encourage clients and servers to link however they wish.

So, let’s go back to our original list and see how we did…

And it turns out there is a project that has these as its goal. The Application-Level Profile Semantics or ALPS Project.

Here’s an ALPS document that describes the WebMention pattern from IndeWebCamp;

ALPS sets out to describe ‘real world concepts’ instead of implementation solutions. In fact, an ALPS description does not include any implementation details at all.

In fact, ALPS documents contain only domain-spcific semantics (data and transitions) without any details on protoco, format, or workflow. When a server sends a response to a client, that server can ‘mark’ the response using a Link header with a "profile" link relation value. In the use-case shown here, the link header tells the client ``This server is speaking webMention now."

As long as the client recognizes that magic string in the link header, then the client and server have been properly introduced and can now successfully interact.

That covers the first rule.

ALPS documents do not indicate a hierarchy of resources. Instead, ALPS documents list all the possible state transitions in this problem domain. Servers and clients are free to implement or ignore these transitions as thery wish.

And, since ALPS documents are not intended to be exclusive, servers can add other links to their responses for clients to pay attention to. In fact, this WebMention example is nice because some of the transitions and data elements appear in the client representation and others appear in the server representation.

Note that the added links are not a problem here. Clients can follow them if they like whether they recognize them from some other specification or maybe the client is programmed, like Dug, to perk up whenever something ‘new’ appears in a response.

Finally, you have the idea of variants of the WebMention ALPS implementation. Not all servers and clients need to do it exactly the same but, like the Web today, the more popular and reliable implemementations will start to get the lion’s share of the links. That means the Power Law is in effect and better implementations can rise to the top organically.

And that means we can build a web of applications similar to how we are building a web of data.

So, what does it all mean?

Maybe ALPS can doo all the things we talked about. It’s very early in the going. The spec has not even been released as in Internet-Draft.

and even if it becomes a draft or even an RFC, will be people use it?

It may turn out the ALPS solves a problem in which few people are interested. Or, it may turn out the other formats can do a better job of describing services in a Web-like manner. I’d love to talk about it and get your ideas and feedback.

And as a final note to get us started, here are just a few thoughts:

and, with what we have before us, I think we can work toward…

Thank you.

Similar to LOD, but instead of a focus on data, a focus on actions or use-cases.

The Web is based on links. [quote].

Not just URLs. URLs are the way we create and share links.

This is the outline of the paper: