An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

The CFML Advisory Committee

April 10, 2009 ·

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:
  • 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.
A new extended core feature is viewed slightly less rigorously but those three basic criteria still apply to some extent.

Tags: adobe · cfml-advisory · coldfusion · openbd · railo

7 responses

  • 1 Brad Wood // Apr 10, 2009 at 9:11 PM

    Thanks for the update Sean.
  • 2 Sami Hoda // Apr 11, 2009 at 12:36 PM

    Good stuff. We'll be following this keenly.
  • 3 John Allen // Apr 11, 2009 at 7:08 PM

    Thanks Sean. Glad a good one is on the committee.
  • 4 Sean Corfield // Apr 11, 2009 at 8:19 PM

    @John, I'd say all seven of the committee are &quot;good ones&quot; :)
  • 5 Vince Bonfanti // Apr 12, 2009 at 10:29 AM

    What mechanism is in place to receive comments from people who are not on the committee?

    That are two tags listed as &quot;core&quot; that I don't think meet your first criteria of &quot;cross-platform and technology neutral&quot;: CFIMPORT (for JSP taglibs) and CFOBJECT (for COM, CORBA, and Java objects).

    Does the committee really expect COM and CORBA support to be implemented by all vendors?

    Requiring support for JSP taglibs and Java objects dictates a Java-based implementation, which is not &quot;technology neutral.&quot;
  • 6 Sean Corfield // Apr 12, 2009 at 11:11 AM

    We'll probably put a contact form on the wiki at some point but I'm pretty sure folks can email the committee at group at opencfml dot org but if we start getting spam on that, we'll disable it.

    We haven't dug into the attributes / arguments on functions yet so whilst the committee consider CFIMPORT and CFOBJECT - createObject() - to be core language, that doesn't mean all attributes / arguments will also be considered core.

    For example, CFIMPORT lets you &quot;import&quot; a directory full of custom tags and I expect we'll decide that is &quot;core&quot; but the JSP taglib functionality will either be &quot;extended core&quot; (optional but implemented the same way by engines that support it) or &quot;vendor specific&quot; (all bets are off, essentially).

    For CFOBJECT, &quot;component&quot; will be &quot;core&quot; and &quot;java&quot; will be either &quot;extended core&quot; or &quot;vendor specific&quot; I expect - and &quot;corba&quot;, &quot;com&quot; and &quot;.net&quot; will definitely be &quot;vendor specific&quot;. I don't know what we'll decide on &quot;webservice&quot; but I suspect that will be &quot;extended core&quot; (or possibly &quot;core&quot; since all vendors currently support it I believe, regardless of technology).

    Attributes and arguments are next on our list to tackle.
  • 7 Aaron West // Apr 14, 2009 at 10:49 AM

    Sean, thanks for posting this overview on where you guys are with documenting CFML, it's very helpful for everyone to know where things are in the process.

    As far as core vs extended core goes, and the examples you posted in your comment to Vince... I wonder if having part of a tag or function be considered core and other parts extended core is just going to make things confusing for developers who are choosing an implementation and vendors who are creating implementations.

    While I understand the reasons for making parts of a tag or function core (because they are platform-agnostic) I wouldn't want to have to keep up with this as a developer or manager. It's a bit too granular. Just my thoughts (which might change as I think more on this topic).