CFML Advisory Committee
Welcome to the CFML Advisory Committee website. Our goal is to define what is "core" to the ColdFusion Markup Language, how that core should behave and what is considered "extended core" - what language features useful CFML processors should implement - as well as offering guidelines for vendors to provide extensions to CFML in a consistent manner.
We are currently finalizing our basic definition of what constitutes the core CFML tags, functions and script and will be publishing more details shortly.
This status report is current as of July 14, 2009.
The OpenCFML committee has moved the wiki to Confluence. While the software process is done, we are still working on getting approval from Confluence for an open source-related license. We have also moved to JIRA to help track issues. This URL will be released later.
There is still serious discussion involved around CFSCRIPT, especially in regards to handling older tag based custom tags and other tag related issues. …
Definitions
We have divided CFML into three areas: "core", "extended core" and "vendor-specific". The intent behind these terms is as follows:
- Core: A feature defined as core CFML is intended to be implemented the same way by all vendors. If developers write code that uses only core CFML features, they can expect their code to be portable across all engines that implement the specification.
- Extended Core: A feature defined as extended core CFML is optional but is intended to be implemented the same way by any vendor that chooses to support it. If developers write code that uses only core and extended core CFML features, they can expect their code to be portable across those engines that implement all such features that the code uses.
- Vendor-Specific: A feature defined as vendor-specific CFML is optional and may well be implemented by only one vendor or may differ between engines. If developers write code that uses any vendor-specific features, they should have no expectation of portability.
We plan to issue a CFML specification approximately every two years. Each published specification will mainly be a codification of the language as it is supported by the majority of vendors at a given time - although each will also include some features not yet supported by every vendor. The intent is that vendors will aim to implement the full core specification within a reasonable timeframe.
Core Language Definition
Early on in our discussions, we agreed that "all" of cfscript is considered core language. Obviously this will need to be further refined since cfscript is not yet very well documented or specified and it sounds like Adobe are extending cfscript in their upcoming "Centaur" release.
Extended Core Language Definition
This category contains tags and functions that are considered important and "should" be present in every CFML processor but are not really core to the language itself. We'll flesh out this section after we've specified the core language.
Vendor-Specific Extensions
This section will list tags and functions that we consider to be vendor-specific extensions to the language (even if all vendors implement them) as well as providing guidelines for vendors to add new tags and functions in a consistent manner.
The Committee
The current members of the committee are:
- Rob Brooks-Bilson - Community / Amkor Technology
- Raymond Camden - Community
- Sean Corfield - Railo, committee chair
- Peter J. Farrell - Community
- Ben Forta - Adobe
- Adam Lehman - Adobe
- Matt Woodward - Open BlueDragon
