Agility - a new reason to like community-based specifications

Body

I review all the Linked Data/OSLC-based APIs we release in Cloud and Smarter Infrastructure; see Tuan's post if you want to see some of the scenarios driving these APIs.  Today I was looking at some data from a prototype, and I saw someone trying to do something I had not seen before in practice that looked suspect, so I wanted to refresh myself on what the specification did say in this area.

This happened to be the OSLC Automation specification.  It's one worth paying some attention to, if you worry about, well.... automating things.  It's showing up in more places now, some already available and some still in beta.  Until I do a more complete post on Automation proper, either here or in my "not only JazzSM" blog, suffice it to say that the point in question has to do with passing parameters, which in Automation unsurprisingly means name-value pairs.  This is not interesting because I could look up my answer (that would be just a specific example of following my nose), but rather because I found some things wrong (under-specified) and we don't have to force implementers to live with them for months/years.

• I found a pair of broken links - obvious typos in the anchor href values.  Since it's a wiki, and this is a working group I happen to participate in, I could just fix them - even though it's a "finalized" spec.  I did notify the working group, simply for transparency's sake; my first W3C Team Contact taught me well.
   
• I found a statement that's clearly not correct as written, and whose intent is not absolutely clear but probably guessable.  I could (and did) just email that issue to the working group.  We meet tomorrow (sometimes my timing is just good), and odds are it will be on the agenda.  We'll resolve it and update the wiki copy, I'm betting pretty quickly.
   

In both cases, no one need ever see these problems again - they're usually fixed within a few days.  That's agile.