>Eclipse Bug Day:
Just a reminder that Eclipse Bug Day is August 29, 2008. This is a great way for people that want to learn about eclipse or to fix that annoying issue that has been bugging you. Most of the bugs choosen by the committers for bug day are deemed to be entry level. Some may be a bit more involved than others though. I personally started my adventure into eclipse development about a year ago.
Anyways, I encourage those that haven’t already to roll up their sleeves and fix a few annoying bugs. Here are the XSL Tools bugs.
Contributing back to Data Standards:
One of the things I’ve seen over the years is a reluctance from users of Data Standards to contribute back their requirements. It doesn’t matter whether it is a data standard based in XML, EDI, or EDIFACT. There always seems to be a reluctance to share the meta-information that describes the data being exchanged. This has lead to many standards organizations when implementing XML as the format, to go with the concept of a User Area. Where users can add their own requirements. Unfortunately, this tends to lead to many one off implementations, causing more headaches for users that have to deal with multiple trading partners. It defeats the purpose of the data standard.
One of the things that has to be considered when deciding if it is in the best interest or your company to extend the standard or contribute back is where is the data going to be seen. If you are using a standard like OAGIs as a canonical model for internal use only, then using user areas might be worth while. You aren’t affecting anybody else but your internal applications and organizations. However, as soon as you start to exchange those same messages outside of your internal environment, then it is probably best to get them officially incorporated into the standard.
The less that your outside trading partners have to deal with creating one off implementations of the same message for each of their trading partners, the faster they can respond to enhancing their applications for you and their other customers. If they are spending all of their time doing one off implementations, it takes away from time they could be adding new features and functionality to the applications that support the standard.
Data requirements aren’t necessarily what gives somebody a competitive edge, it’s the features and functionality of the application. A data standard should help reduce the amount of one off implementations that somebody has to create, not increase it.
Common Reasons for Extension
Here are some of the reasons I’ve commonly seen for why people extend:
- It takes years for the requirements to get added.
- Data is unique to the application.
- I’m the big gorilla, so I don’t need to contribute. Everybody has to do what I say anyway.
- I need it now not 6 months from now.
Most other reasons are similar. Some of this is the fault of the Standards organizations themselves. Designing by committee can be a slow process, but if an organization doesn’t have set target dates for releases, items will get bogged down. Organizations should review their structures to make sure they are only doing what is necessary, and not allowing themselves to get overburdened with needless process and check points. Agile development processes can be applied to standards development, it just takes a willingness to review the current process and get rid of the unnecessary overhead. Unless the fundamental process of development of these data standards changes, people will always have a reason to extend. If the organizations can incorporate and publish the standards sooner rather than later, the business need for extending diminishes.