Friday, May 30th, 2008

Call for Feedback on OpenAjax Conformance and OpenAjax Registry

Category: OpenAjax

>Jon Ferraiolo of IBM and the OpenAjax Alliance wanted to share with the community news on a couple of initiatives:

The OpenAjax Alliance is requesting industry feedback on two companion initiatives, OpenAjax Conformance and the OpenAjax Registry, which have been under development for the past year.

The term OpenAjax Conformance is shorthand for the set of conformance requirements that OpenAjax Alliance places on Ajax technologies, products, and applications to promote interoperability. Version 1 of OpenAjax Conformance defines 10 specific conformance requirements on Ajax runtime libraries. An Ajax runtime library that meets these conformance requirements will allow Web developers to use that library conveniently within a given Web page with other OpenAjax Conformant libraries.

OpenAjax Conformance provides the following benefits to IT managers and the Ajax developer community:

  • Seamless integration of multiple Ajax products and technologies within the same Web application, particularly with applications that use mashup techniques
  • Greater certainty about product choices, where OpenAjax Conformance plays a similar role in the Ajax community as the Good Housekeeping Seal does with consumer products
  • Lower training costs, lower development costs, and faster delivery of Web 2.0 innovations due to industry adoption of common approaches that build from OpenAjax standards
  • Interchangeability of OpenAjax Conformant products, such that customers can choose among multiple vendors (and change vendors in the future)

OpenAjax Conformance defines three conformance levels. Full Conformance is for Ajax products that have sufficiently strong Ajax interoperability characteristics that there is high expectation that the given product can be used successfully and conveniently with other Ajax products as part of the same Ajax development task. Configurable Conformance is for Ajax products that support all of the same strong interoperability characteristics as for Full Conformance, except not in their default configuration. Limited Conformance is for products that meet a particular subset of the conformance criteria, and therefore have taken important steps towards Ajax industry interoperability, but on the question of whether the given Ajax product can interoperate successfully and conveniently with other Ajax products, the answer is “it depends”.

The OpenAjax Registry is a centralized, industry-wide Ajax registration authority managed by the Interoperability Working Group at OpenAjax Alliance. The Registry maintains an industry-wide list of Ajax runtime libraries and various characteristics of each library. For each library, the Registry lists:

  • JavaScript globals
  • runtime extensions (both JavaScript and DOM)
  • markup extensions (e.g., custom elements, attributes or CSS class names)

These two technologies have now entered a public review phase that ends on June 30, 2008. Feedback can come in various forms, such as email to public@openajax.org, or comments posted on various industry blogs. After the public review phase ends, the members of OpenAjax Alliance will adjust the two specifications to take the feedback into account and then move the two specifications towards version 1.0 completion and approval.

Related Content:

  • Java EE 6 Overview
    The details of Java EE 6 have been getting hashed out for quite a few months in the JSR 316 expert group, which I am part of. The goal of this article...

Posted by Dion Almaer at 1:52 pm
6 Comments

+++--
3.6 rating from 20 votes

6 Comments »

Comments feed TrackBack URI

It’s amusing to see how many globals Microsoft declares. On the opposite extreme, The UIZE Framework tucks all its goodies under the single global of the Uize object. Being as short and as sufficiently unique as it is, this minimizes chances of namespace collisions. I don’t feel bad about staking claim to just this one global.
 
Also, it’s sad to see discussion around managing conflicts in extensions to native objects, such as new methods for String, Object, Number, etc. I realized a long time ago in my JavaScript career just how bad of an idea it is to utilize this tantalizing capability in JavaScript, in terms of interoperability of code. So, UIZE takes the approach of providing utility packages of helper static methods. I think the reason extending the native objects is such a teaze is because it gives you the sense of the power to shape the evolution of the language – but it’s a potentially disastrous idea for real world application interoperability.
 
On the subject of globals in general, if you find you’re having to rely on too many of them, then it suggest that something may be going wrong in the architecture design – insufficient encapsulation in the design. I would see this is a red flag.
 
http://www.uize.com

Comment by uize — May 31, 2008

Oh, and let me add… I do think it’s a good idea to have the registry and I applaud the people behind it.

Comment by uize — May 31, 2008

I agree that augmenting built in objects is a mistake. Unfortunately some influential people disagree and use the technique even when it is completely unnecessary. For example:

http://tech.groups.yahoo.com/group/json/message/1028

Comment by PeterMichaux — May 31, 2008

“Repairing” the JavaScript language by adding extensions to its native objects is kind of like being a vigilante and taking the law into your own hands. This reminds me of the wonderful and fun days of different browser vendors “taking the law into their own hands” and “repairing” HTML by adding their own extensions to HTML and to CSS. Standards bodies to the rescue, and finally it is reasonably livable to do cross-browser coding without wanting to kill yourself.
 
I don’t want to turn the JavaScript language into a kind of Wild West where you can’t do cross framework coding and mixing code that uses different frameworks, because everyone is trying to extend and repair JavaScript to suit their own specific sensibilities. Someone’s gonna want to make it more like Python, Ruby, or Java, or whatever. Before you know it, JavaScript no longer can maintain a single core identity.
 
Introducing new features to the language should be channeled through a standards process. I feel adamant about this, and so – in this respect – I openly challenge Douglas Crockford’s viewpoint on the matter. In other respects, I deeply appreciate his efforts in championing the utilization of JSON.

Comment by uize — May 31, 2008

Hi uize, add me up as an “open challenger”…
I couldn’t agree more with you :)

Comment by polterguy — June 1, 2008

Yeah it is right
I can agree.

Comment by Tribulus — September 22, 2008

Leave a comment

You must be logged in to post a comment.