I have been following the thread about PaceMagicId [1] closely, as it is a topic of somewhat importance to Six Apart.
But what I see in the sub-text of the conversation is a debate about how explicit the Atom specification should be in cases where clients and servers could implement/interpret the spec *slightly* differently. I think as a group, it would best serve us to address that debate directly. Should we, as a rule: 1) Err on the side of openness Leave the spec clear on what to implement, but don't go overboard on specifying minute details. This I believe makes the spec easier to implement, and may help drive adoption. 2) Err on the side of specificity Don't leave a lot of ambiguity in the spec. Be clear and specific about what exactly needs to be implemented. This has the benefit of optimizing for interoperability, but at the expense of slowing down the concensus building process. -- Part of me wants to take a lesson from the SOAP WG. Pretty decent piece of work IMHO, with a pretty good rate of adoption. It's beauty, SOAP encoding aside, was its simplicity. Ultimately, however, it was insufficient and necessitated that an entirely different group to assemble interoperability guidelines (WS-i). And this is precisely he problem I want to address: interoperability. I am fine to forego many debates about how a client and server should respond in specific edge cases, but there should be an acknowledgement within the group that if WE don't address the problems around interoperability, someone else will have to. That being said, what I think this group needs is a set of core principles that we can fall back on when contentious debates arise. That is not to say that the debates should not happen, not at all, but having these kinds of "values" in place would give the editors a set of guidelines to follow when trying to incorporate everyone's feedback. My feeling, despite my desire for us to be specific whenever we can, is to err on the side of openness. I believe that being slightly more open ended (perhaps that is not the right choice of words) in our spec language will help us to build concensus more quickly as a team, iterate on the spec more rapidly, and get something into the hands of the broader marketplace, which ultimately (and perhaps unfortunately for that matter) will be the final arbiter of what this WG produces. Furthermore, I believe openness and simplicity will help drive adoption by developers because the spec won't be nearly so daunting. A good example of how we might do that is to compare PaceMagicId [1] and PacePostAnyToEntryCollection [2]. In that example, I would favor PacePostAnyToEntryCollection for all the reasons stated above. Meanwhile, we should consider taking issues of interoperability to another mailing list of group for discussion and resolution. Thoughts? [1] - http://www.intertwingly.net/wiki/pie/PaceMagicId [2] - http://www.intertwingly.net/wiki/pie/PacePostAnyToEntryCollection Byrne Reese Manager, Platform Technology http://www.sixapart.com/pronet/
