Getting to Know the CFML Advisory Committee

by Rob Brooks-Bilson

It's been about eighteen months now since Adobe first formed the CFML Advisory Committee, both as a way to promote the standardization of the ColdFusion Markup Language across vendor implementations and to provide valuable advice on future design of the language. The name Adobe choose for the group should make evident that the group focuses on the ColdFusion Markup Language itself and not Adobe's ColdFusion server platform.

The current CFML Advisory Committee membership is made up of representatives from Adobe (Ben Forta and Adam Lehman), Railo (Sean Corfield, committee chair), Open BlueDragon (Matt Woodward) and the community at large (Ray Camden, Peter J. Farrell and myself ).

The committee set as its first priority a taxonomy for the language, organizing all language elements across the major vendors into three categories¹:

1. Core: Core CFML features are implemented the same way by all vendors. Code that uses only core CFML features should be portable across all engines that implement the specification.
2. Extended Core: Extended core CFML is optional but should be implemented the same way by any vendor that chooses to support it. Developers who use only core and extended core CFML features in their code can expect their code to be portable across those engines that implement all such features that the code uses.
3. Vendor-Specific: Vendor-specific CFML is optional and may differ between engines or only have one implementation. There should be no expectation of portability for code that uses vendor-specific features.

Starting in July 2008, the committee set out to catalog all of the CFML tags and functions across all three major CFML engines: Adobe ColdFusion, Open BlueDragon, and Railo. Once we identified the language elements, we determined which tags we considered core, extended-core, and vendor-specific . We achieved this by voting on each individual tag and function, tabulating the results, and resolving any items where we didn't have a consensus. A Google spreadsheet facilitated the collaborative nature of getting seven people to vote on hundreds of individual items. This process took about six months to complete and we published our results to the CFML Advisory Wiki located at www.opencfml.org on Jan 9th, 2009.

Once we completed work on the initial language taxonomy, the group set its sights on creating a formal specification for CFML and cfscript called CFML2009 that vendors could use as a guide for implementing the CFML language within their respective engines. It consisted not only of the language taxonomy we created but also recommendations for how to implement syntax — how both to implement existing and new tags in cfscript for the then-upcoming release of Adobe ColdFusion 9.

Around the same time we started working on the CFML2009 spec, Adobe ColdFusion 9 went into beta. Even though Adobe had already defined many of the new features for ColdFusion 9, they spent a considerable amount of time working with the committee to get ColdFusion 9, specifically cfscript, as close to the CFML2009 spec as they could.

The final version of ColdFusion 9 that shipped in November 2009 was consistent with the CFML2009 spec in many ways, with some significant differences. For example, our recommendation to Adobe concerning how lock should be implemented in cfscript looked something like this (from Sean Corfield's blog):

What Adobe ended up implementing was this:

There are other examples of deviations from our proposed specification, but that's not important at this point. The committee heavily influenced major additions to the ColdFusion Markup Language in Adobe's ColdFusion 9. Given the fact that the committee didn?t start their work until well into the Adobe ColdFusion 9 development cycle, Adobe demonstrated considerable willingness to work with the committee and to make sometimes significant changes to their plans, based on the feedback and suggestions from the committee. While it would have been great to see Adobe ColdFusion 9 exactly match the CFML2009 spec, in practical reality, there was just too much work to be done and not enough time to do it.

The fact that the Adobe ColdFusion 9 implementation doesn't fully follow the CFML2009 means we have a spec that won't match any of the major CFML engines, as both Railo and Open BlueDragon will most likely follow Adobe's implementation. Since the committee wants to promote standardization across implementations, it doesn't make much sense to continue on with the current spec. It wouldn't do much good if Railo and/or Open BlueDragon went and implemented their next major releases based on the CFML2009 spec only to have Adobe with a different implementation — the horse has already left the barn. Rather than looking at this as a failure, we view it as a learning experience. We've learned some valuable lessons and plan to put those lessons to practical use as we set our sights on creating a new version of the spec.

The committee currently intends to produce an updated spec for CFML every two years. As such, it already has some plans for the CFML2011 spec. We will revise what we wrote for the CFML2009 spec to reflect what each of the CFML engines actually implemented as of the Adobe ColdFusion 9 release. For the CFML2011 spec, we hope to be ahead of the curve in providing guidance to the CFML engine vendors. We want to concentrate on drilling further down into the functions and tags of the language, cataloging and standardizing (where possible) the arguments, attributes, parameters, and operators across engines. That's a seriously daunting task given the number of tags and functions that make up CFML. To this end, the committee is considering ways we can crowd-source the effort. Expect to hear more about that as our roadmap starts to take shape.

The committee has set as another goal a more transparent process for the CFML2011 spec. Sure, various members made sporadic blog posts and tweets over the past year and a half, but we never formalized our communication and feedback processes. That will improve going forward as we seek to incorporate more feedback, and at times direct help, from the CFML community in producing the CFML2011 spec. To stay up-to-date on our plans, keep an eye on the official website of the CFML Advisory Committee at http://www.opencfml.org.

¹Categories defined by the CFML Advisory Committee and published at http://www.opencfml.org

Rob Brooks-Bilson is a consultant, freelance writer and the Director of Architecture at Amkor Technology. His involvement with ColdFusion goes back to version 1.5 and includes many Enterprise projects, the creation of numerous open source custom tags, and co-founding CFLib.org. Rob is an Adobe Community Professional for ColdFusion, a member of the CFML Advisory Committee, and is a frequent speaker at ColdFusion user groups and conferences. Over the years, Rob has written many articles on ColdFusion and other technologies for various print and online magazines. He's also the author of O'Reilly's Programming ColdFusion and Programming ColdFusion MX.

• Subscribe
• RSS

• Editorial
• Specials
• Community
• News
• Tech and Tags
• Views
• Reviews
• Techniques
• Security
• Best of ColdFusion Talk
• Knowledge Base
• Blog Watch

• Tipical Charlie