Update: via a recent follow-up comment from Yaron Goland,
I have now sent full descriptions of our issues to the APP working group and the general consensus, led by Tim, was that what we are doing really doesn’t fit APP.
APP’s sweet spot is just different than Web3S’s. As I showed in my postings it is possible to expose Web3S data via APP but the results tend to be a bit, well, messy and don’t really fit the spirit of APP.
My expectation is that when we have data sources whose behavior fits well with APP we would want to expose them as APP. There is no universal solution to anything. It’s a question of the right tool for the right job.
In reading through the post’s mentioned above, my own take is that members of the AtomPub WG somewhat informally agreed w/ the outcome of the decision to implement Web3S the way they did, just not with the way it was initially presented to the world. In this regard it seems that the Third World^Wide Web War was avoided, and the end of the Cold^WWW War is at very least a plausible scenario.
Any active AtomPub WG dev-list members out there interested in providing your own summary of the events that took place?
[Original Post]
Summary: Web3S is Microsoft’s answer to a RESTful web publishing protocol. In many ways it attempts to tackle the same problems solved by the Atom Publishing Protocol. For various reasons** MSFT found APP to be insufficient for their needs. In a follow-up comment to Yaron Goland’s announcement regarding Web3S, Joe Gregorio asked,
“The spec was obviously still in the works when you were working on WebS3 and if you believed you had found real weaknesses with APP, which the ensuing discussion has shown that you didn’t, then why not bring attention to them before we shipped?”
to which Yaron responded with,
As for approaching the TC, I actually did talk with folks in the APP community and they gave answers much like those we received as part of the responses to Dare’s post. As I explain above we do not believe those answers actually solved our problems. Nevertheless we should have gone to the TC. This is a mistake I will remedy forthwith.
Okay, now you’re all caught up. On to the good stuff,
BTW, a critical point to keep in mind in this discussion is that Web3S hasn’t ’shipped’. There does not exist a Web3S service anywhere in the world that I’m aware of. The point of making the Web3S specs available before we have an implementation is to say - PLEASE GIVE US FEEDBACK!
Or in other words,
Hopefully a discussion in the TC will lead us either to understand why we are wrong in our analysis or perhaps the TC will decide that, in fact, APP doesn’t meet our needs and perhaps decide to discuss what changes could be introduced to make it a better fit. But in either case the first stop is the TC.
No sign of a post to the APP Working Group list as of yet. But unless I am completely off target, we are about to witness either the beginning of the the Third World^Wide Web War, or the end of the Cold^WWW War. Either way, history is in the making…
Stay tuned. (< I assure you, I’ll be keeping you posted on all the significant details, without a doubt! ;-)
Update: After a quick parsing of the Web3S spec, I have come to the following potential conclusions,
* There is some *killer* stuff in here!
* If MSFT and the APP WG could come to an agreement in regards to how to integrate the various pieces of this that are not already solved by APP as *extensions* to the APP spec, the world will be a better place because of it.
* The following talking points from the spec I believe are absolutely *MANDATORY*, and regardless of whether APP+Extensions and Web3S become one in the same, these issues need to be discussed, and a specification developed around each one of them,
10.4 XPATH Query Segment Extension
[OPEN ISSUE - 3SAFO - We need to define a mechanism by which to submit xpath queries on request URIs across the Web3S Infoset.]
10.5 SEARCH Method Support
[OPEN ISSUE - 3SAFP - We need to look at DASL et al. to see if we can define a more generic way to submit Web3S queries. We also need to think about supporting XQuery.]
10.6 Serializing the Web3S Infoset into/out of JSON
[OPEN ISSUE - 3SAFQ - We need to specify how to serialize the Web3S Infoset into/out of JSON.]
–
** BTW: Dare, *thanks* for switching to a /year/month/day/title.ext format for your blog!
I think this debate really came the wrong way. Dare ought to have been a more careful regarding his words. However the AtomPP community may have been on the defense side a bit too much as well. But that's expected when people coming from competitors try to debate or when bold claims are made.
No matter the technical reason behind the choice of specifying their own RESTful protocol, I think Microsoft again shot itself into the foot on this one. It appears they have reviewed AtomPP extensively enough to make the decision it wouldn't suit their needs. That's entirely fine and as James Snell said [1], if Dare had claimed that AtomPP wasn't suited for Windows Live instead of predicting its failure this would have been a whole other story.
What annoys me most is that if you understand the limits of a protocol why don't you jump on the relevant WG (which is extremely open) to actually inform the right people at the right place at the right moment about your concerns. Looking at what they found limitating I don't think they would have managed to shift the protocol but that would have been a very fertile discussion in regards to context where the protocol may not work out well out of the box. Instead what the Microsoft people did, well nothing. Sure Yaron acknowledges that mistake and promises to fix it but I'll be careful until we see something concrete.
The worse is that even though I'm sure the Microsoft guys are brilliant guys they do look again like they don't want to play with the rest of the World. Maybe not Yaron or his team but it does look again like Microsoft has that spirit of "screw them let's do it our way". Personally I tend to believe that teams like Yaron's one receive some crazy business goals from the top and they must find the quickest way to implement those and can't afford the luxury of going open about it. No matter what that leads them to get screwed over when things like this hit fan.
I'm slightly bitter about this story because as you point out here Web3S addresses some issues that future implementations of AtomPP will certainly meet to a certain extent and Microsoft would have looked better by submitting them to the WG rather than playing their own game once again.
That sucks.
@Sylvain,
Let me first make the statement that I personally don't believe in conspiracies. I believe in opportunities, which is exactly what I believe has taken place in this particular regard.
Let me explain,
Firstly, MSFT obviously has a business reason behind developing a publishing protocol that allows developers from all walks of life to read/write from the massive database that is represented by Windows Live. In this regard, there is a definite risk that is taken when diving into a standards group, *especially* when that same standards group is going to question, re-question, and then re-question the re-questions yet one more time in regards to the intent and purpose of Microsoft's push in one direction or another. When you have a market-induced deadline which has been set by the competition moving faster than you, there is simply too much risk involved in stepping into a situation in which at very best is going to leave you wounded and limping, and at worst is going to leave you several years further behind than you already are.
Of course you have to consider the fact that there is a very good chance that the Web3S work began moving forward over the last 12-18 months, potentially even more recent than that. It wouldn't take much more than a simple search of Tim Bray's blog to understand that "APP will be here any day now" and has been that way for that entire period of time (keep in mind that Atom reached final recommendation just under two years ago, and at that stage of the game, APP was already fairly well defined, if not in specification, at very least in purpose.)
With all of this in mind, do you really believe that MSFT should have jumped into things head first knowing full well that their competition would have looked at this as the perfect opportunity to analyze every single move they made, using the court of public opinion as the fuel to ignite the flames of the "we hate MSFT" web masses?
I personally believe it would have been a HUGE mistake, being better served by staying out of the way until such time as APP was at the point where nothing they could say or do would stop it from being given the official RFC rubber stamp. In this regard, herein exists the opportunity,
* When the APP dust has settled, inject into the "conversation" an APP.Clone().Extension.WindowsLive.Data that fits their specific needs for a RESTful web publishing API.
* Make sure that all of your immediate needs are met with this aforementioned API such that you can begin to move things forward, regardless of the approval/rejection of the APP working group of these same suggested changes/extensions.
* Publish the spec using a license that allows anyone to do anything they might want with it, requiring nothing more than attribution for the original parts of the work. (Web3S is licensed under a Creative Commons Attribution 3.0 license)
* Invite anyone and everyone to punch holes in it, find ways to adapt APP to fill the same needs served by other means, and in other forms get the collective intelligence of the web hacking masses, and in particular the collective intelligence of the APP WG members, to tweak and twist and turn and etc. in all the ways they might desire, weave the ideas and solutions presented in Web3S into APP.Next() (AKA APP.Extension.*)
* Walk away from it all *ALIVE*, both in mind, body, and spirit, having contributed to APP on terms that allowed them to maintain control of their own destiny in regards to the ship date as well as the aspects of the collective result they ultimately dub the Windows Live Contacts API.
One could argue: "It's not fair! They should have contributed this work to the APP working group!" and in response I would state: "They just did."
Well I do understand the business and political aspect of this but my point stands as why Microsoft will never stop being seen as evil. They play a game that is dangerous. Mind you I don't believe that (so-called) managers who make (so often poor) decision of choosing one or the other technology reads the rant of a few technologists, even you're called Tim Bray so yeah I bet from a business POV this makes sense and this also makes sense Microsoft competitors are pissed off. Because at the end this is what Microsoft cares about as a company right but so does IBM, Sun or Google.
@Sylvain,
Well, I think what this all comes down to is this,
Does the community want contributions from MSFT or not?
If the answer is no, then obviously MSFT did the right thing in the first place by staying away.
Watching interactions in other companies poised to enter standards work where they have no existing products or market share, just intense and well-financed interest in the market itself, we will see more examples of the style of interactions and the results of applying that style.
MS has played very hardball at times and do bear responsibility for the suspicion, but others who were thought to be above that did that too and are quickly acquiring the same reputations. OTOH, as a result, there is now an endemic "Anything but Microsoft" mentality pervading some in the web worlds and leaking into other business and political arenas. This is too similar to other zealous events in the world to warrant direct comparison, but it does mean for all that thinking hard about the other guy's position before entering these frays is about all we have.
Start from the assumption we all want to make money doing this, but that after that, only sociopaths live for the kill. Then adjust your sights to get the values you desire for the values you have. I don't find MS that hard to work with or at least any harder than any other multi-headed hydra with a lot of power over our lives these days.
@len,
>> Start from the assumption we all want to make money doing this, but that after that, only sociopaths live for the kill. Then adjust your sights to get the values you desire for the values you have. I don't find MS that hard to work with or at least any harder than any other multi-headed hydra with a lot of power over our lives these days.
I have now sent full descriptions of our issues to the APP working group and the general consensus, led by Tim, was that what we are doing really doesn't fit APP.
APP's sweet spot is just different than Web3S's. As I showed in my postings it is possible to expose Web3S data via APP but the results tend to be a bit, well, messy and don't really fit the spirit of APP.
My expectation is that when we have data sources whose behavior fits well with APP we would want to expose them as APP. There is no universal solution to anything. It's a question of the right tool for the right job.
@Yaron,
>> My expectation is that when we have data sources whose behavior fits well with APP we would want to expose them as APP. There is no universal solution to anything. It's a question of the right tool for the right job.
Microsoft has web services?
@Tom,
Are you trying to be funny?