[OpenAjaxIDE] Microsoft Ajax metadata format quick start guide

Alex Russell alex at dojotoolkit.org
Thu Jul 12 12:31:14 PDT 2007

Hey Jon,

On Thursday 12 July 2007 11:39 am, Jon Ferraiolo wrote:
> Hi Alex,
> Actually, this is a hot topic within the Interoperability Working
> Group that will be on the agenda for the next phone call. We talked
> about it briefly at the Interop phone call on Wed. and I promised to
> take a crack at this very tough issue so that we have something
> concrete to discuss before the next Interop phone call. (Scheduled in
> 2 weeks, but that's overlapping Ajax Experience, so we might have to
> postpone.)

It's also OSCON.

> While I agree that OpenAjax should not condone extending JavaScript
> as any sort of officially sanctioned best practice, we have to deal
> with realities where some very popular Ajax toolkits extend
> JavaScript and at least some will refuse to give up on this.

Right, but we don't have to sanction what they're doing. We're 
responsible for the predictable consequences of what we as OAA do, not 
much beyond that.

> Therefore, I was thinking about having the OpenAjax Registry define
> at least two categories. One category would be the list of approved
> globals, such as [window.]openajax and [window.]dojo. For Microsoft,
> they use [window.]Sys as the root for most of the features in their
> runtime.

I'm relatively militant about this. I think the first list is the *only* 
official list we should keep. If vendors define things by default that 
are off the list, they should get an asterisk next to their name and 
potentially a lower level of certifcation. Further, any conditional 
certification should be contingent upon them listing in a very public 
way what the additional globals are and noting how badly this behavior 
can screw you (with OAA approved language, think "surgeon general's 

> The second category would be the list of JavaScript 
> extensions (which we preface with comments about major
> interoperability problems from extending JavaScript, but how the cat
> is out of the bag, so OpenAjax is defining a mechanism for addressing
> these extensions).

I'm having trouble imagining the value of this. ISTM that vendors should 
be able to do what they like, they just don't have any right to expect 
us to condone it. We are a component-branding organization. We build 
credibility and brand by ensuring that things actually work as we say 
they will and that that way is *good* for users (not simply net neutral 
WRT the current state of the art).

> The general idea is that OpenAjax would define 
> some rules about JavaScript extensions, such as (1) there needs to be
> a complete spec for an extension, 

How are we defining "complete"? And do we (OAA) bear responsibility for 
approving them? Seems like a lot of effort on our part for something 
vendors should just never do in the first place.

To quote Mike from Office Space: "Why should I change? He's the one who 

> (2) there needs to be a commitment 
> that future versions of the extension will be backwards compatible,

So that's pretty large dis-incentive to actually registering their 
extensions. What if they do the right thing in the future and remove 
them? Are they still bound to provide them?

> (3) for each extension we would identify someone in the industry as
> the owner of particular extensions. (Something like that.)

I can imagine vendors bludgeoning each other with "your behavior isn't 
100% compatible w/ how we defined it at OAA, so you need to change your 
code" and then following up w/ "now that you're bugwards compatible, 
you're in violation of our copyright". Ugg.


Alex Russell
alex at sitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20070712/a5477e3b/attachment.bin 

More information about the IDE mailing list