[OpenAjaxIDE] Microsoft Ajax metadata format quick start guide
alex at dojotoolkit.org
Thu Jul 12 12:31:14 PDT 2007
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
It's also OSCON.
> as any sort of officially sanctioned best practice, we have to deal
> with realities where some very popular Ajax toolkits extend
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
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
> extensions (which we preface with comments about major
> 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
> 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 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
Size: 186 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20070712/a5477e3b/attachment.bin
More information about the IDE