How to Change

They say "a change we'll do you good." That "the only thing that is inevitable is change." We know change brings opportunities and challenges and that change is hard. In Part 1 of this series, I wrote about the importance for standards organizations to have a maturity plan in the same fashion that a maturing commercial product would have such a plan. In Part 2, I provided some background on HR-XML's origin and its early years. In this post, I take a look at some of the events that led to the HR-XML 3.0 project.

Tool Troubles

In business and in life in general, someone can tell you exactly what you need to know, when you need to know it, but the information doesn't always get acted upon immediately. I mentioned that in our very early days, Microsoft had helped raise our profile by allowing us to participate in the BizTalk launch. The very gentleman who had been so helpful back in 1999, visited us at our April 2004 New York meeting and gave us a review of our then 2-year-old version 2.* library. Let's just say this was delivered in the blunt manner characteristic of engineers. He covered items such as the complexity of the xsd:includes (see my Part 2 of this series), the use of troublesome schema features (e.g., the way we had used xsd:union within the date types throughout the library) as emphasizing that interoperability required a solid data model - not just XML. He concluded his presentation by saying something to the effect that we could fix these deficiencies or just become another group that travels, eats a lot of "hotel chicken," and shares a few beers together after work group meetings. The presentation did trigger a lot of discussion, but not necessarily any particular next step.