All,
As I alluded to in a previous email, I’ve been trying to read up as much as possible on various information exchange technologies in an effort to try and learn the lessons of the past, and help make TAXII as good as it can be. I came across the Wikipedia page on CORBA, specifically the section on criticisms [1]. I’m sharing in hopes that others will find it interesting as well.
In the criticisms section, I found some particularly salient points that I think are relevant to TAXII. I found the whole section to be interesting, though I’ve attempted a summary for the most critical points:
1. Standards are judged by their implementations, so make your standard easy to implement.
Like it or not, much of CORBA’s criticism was derived from poor quality of implementations rather than any deficiency of the standard itself. Reading between the lines, a less complex CORBA specification would probably have helped create higher quality implementations. I see this as reinforcing the need for “simplicity” and “one way of doing things” that others have contributed to the discussion. It is the onus of this group to create a specification that is easy to implement, so that we can help TAXII implementations be of the highest possible quality.
2. Scope and Prioritization are key, do not try to boil the ocean
I’ll just quote directly from the Wikipedia page: “There was no process to arbitrate between conflicting proposals or to decide on the hierarchy of problems to tackle. Thus the standard was created by taking a union of the features in all proposals with no regard to their coherence. This made the specification complex, expensive to implement entirely, and often ambiguous.”
If there’s anyone out there who wants to follow the described path, please kindly build your Rube Goldberg machine elsewhere. Joking aside, I feel that in practice this is probably an easy problem to identify and a hard problem to solve – I’m sure the CORBA folks would have avoided this criticism if they could have (of course I know nothing of the history, so I may be speaking ignorantly). I think as a group, we need to set a precedent early on where we scope and prioritize our work so that TAXII does not become a union of all suggested features. I don’t think we need a formal process (yet, anyway), but we do need a commitment to work together productively. I give this group my commitment, even if it means a feature I like doesn’t get included.
3. Implement as you build, or you will be standardizing untested concepts
CORBA had no reference implementation requirement, and none was built. Therefore, features were added to CORBA and standardized before anyone spent implementation time to learn how they work. We should only standardize the things that we know to work well. For things we don’t know well, we should work to understand them before standardization, rather than learning about them by standardization. As a corollary, it’s OK to attempt to standardize a feature and end up leaving it out because we don’t understand it well – we can always add it in the future when we do understand it well.
Hopefully that was a worthwhile read.
Thank you.
-Mark