The W3C  is a fantastic organization that has done more than any organization to help promote standards and interoperability on the web. It is also the body responsible for many of the core standards that our uRiKA system utilizes such as RDF  and SPARQL 1.0 .
SPARQL 1.1  is the new version of the SPARQL standard currently working its way through the standardization process and by all accounts SPARQL 1.1 is a substantial and impressive expansion of the original SPARQL standard. It introduces a cornucopia of new features to the existing query standard including important analytics capabilities like grouping and aggregate expressions, and also introduces a new update language for modifying data via SPARQL.
As an avid SPARQL user I’m extremely happy with all the new things going into SPARQL but as an implementer I’m become a little frustrated. Since it is such a high profile technology in the Semantic Web arena the standards process has attracted a lot of feedback around the proposed features, both positive and negative, and I will admit to having contributed myself both formally and informally.
It has also attracted some significant controversy, particularly recently around property paths whose proposed design led to some amusingly titled research papers such as Counting Beyond a Yottabyte, or how SPARQL 1.1 Property Paths will Prevent Adoption of the Standard . This feedback and another paper  prompted the SPARQL working group to announce a redesign of this feature . While this is great for the standard it creates problems for implementers. Either we have yet to implement property paths and must redo our design for this feature or we have implemented the existing standard and must re-implement this feature according to the revised standard.
Clearly there is a trade off here. If we’ve chosen to implement the draft version of the standard because our customers need the features provided by it we are accepting the risk that the standard may change and create additional work for us at a later date. On the other hand, if we don’t attempt to implement the standard how do we give useful feedback to the working group that leads to important revisions like this?
The problem with revisions to the draft standard is when the working group announces major changes as they have done but then doesn’t publish a revised draft and revised test cases in a timely fashion. Without a revised draft we as implementers are loath to revise our implementation because we don’t have a solid design to work to. At the time of writing the working group has still yet to publish a revised draft 3 months after announcing the changes (though I’m reliably informed that this should happen in the next couple of weeks).
Ultimately, though, I still have to say what a fantastic job the working group has done in specifying many important additions to the standards, even if I am sometimes frustrated as an implementer by the pace of draft releases. Defining any new standard is always going to be a long, iterative and often times rocky process. It’s just a shame that the process can cause so much frustration for users and implementers alike as both struggle to hit the ever moving target that is the draft standard.