- A new core feature must be cross-platform and technology neutral.
- A new core feature should be expected to be implemented by all vendors.
- A new core feature should add value to the language itself - rather than the ecosystem.
The CFML Advisory Committee
April 10, 2009 · 7 Comments
It's been a while since I posted anything formally about the committee and I've started to see it mentioned in comments on blogs and on mailing lists lately so I feel now is a good time to update everyone on where we are, what we're currently working on and what we're trying to achieve. First off, you can always check out the CFML Advisory Committee website. We're updating it as we finalize our decisions but it can be a slow process since this is the first time any group has tried to agree on a specification for the ColdFusion Markup Language. Over the last few weeks, the committee has been pretty active...A few months ago we posted our first round of decisions: a breakdown of tags and functions into three categories. Those three categories - core, extended core and vendor specific - are now defined on the website and we're continuing to extend that analysis to cover all the attributes of tags and all the arguments of functions. As you can imagine, this is a big job. We've also been discussing how often we should publish a specification. If we revise the specification too often, it will not provide the stability that both vendors and the community need in order to, respectively, robustly implement new language features and robustly develop portable applications. If we do not revise the specification often enough, it will lag too far behind vendors' implementations and become less relevant to CFML developers. In the end, we agreed to publish an updated specification every two years, starting with "CFML2009" which we hope to publish this Summer. Bear in mind that we are specifying the language itself which is a subset of all the functionality that each vendor may offer. Languages that have been around as long as CFML do not tend to change all that rapidly and if you look at the ANSI/ISO process, each standard is only required to be reviewed five years after publication which can mean up to ten years between language revisions! Once we have CFML2009 published, the committee will focus on providing guidance to vendors on how to add new features in a consistent and idiomatic manner. Many people complain that there are tags that have unique attributes where other tags have adopted a consistent name for a similar attribute. We hope to address this so that CFML2011 can offer a more intuitive and consistent language - as well as a more powerful one. In addition to analyzing all the tags and functions - a massive job that has all the committee pitching in - we plan to specify CFSCRIPT. We stated last year that the basic position of the committee is that "all" of CFSCRIPT is core language but since it is not very well documented, we need to create that documentation. On top of that, Adobe has shared a number of proposals with the committee for enhancing CFSCRIPT - some of which Adobe has discussed publicly as potential enhancements for Centaur. The committee are evaluating all of those proposals to decide which features, if any, should become part of CFML2009. This is the start of what we hope will become a standard process for vendors, offering proposals to the committee for any features they may consider implementing if they also believe those features should become part of the core language. That's an important qualification that I want to expand on because I don't want people to think the committee will act as a "clearing house" for all features that vendors may be considering. The committee is focused on the language itself, rather than any vertical features. If a vendor decides to add, say, <cfreport> that integrates with, say, Crystal Reports on Windows, then that is clearly not meant to be part of the core language and is therefore outside the remit of the committee. The vendor will hopefully take account of the committee's guidance on tag and attribute names when designing their new feature but otherwise does not need to involve the committee on such a feature. The committee can also take feedback from the community on language enhancements. Feel free to email any committee member to discuss your suggestion but bear in mind some criteria that we have to apply when considering language changes: