[OpenAjaxIDE] Microsoft Ajax metadata format quick start guide

Alex Russell alex at dojotoolkit.org
Thu Jul 12 12:04:43 PDT 2007

Hey Bertrand,

On Thursday 12 July 2007 11:08 am, Bertrand Le Roy wrote:
> Hi,
> That subject was discussed at yesterday's meeting.
> Actually, it's a fact that many existing and widely used frameworks
> extend built-in prototypes and instances.

Hence we have a problem that needs solving. That it is so today creates 
no viable case that it *should* be so or that we as a body have any 
business sanctioning such interoperability-destroying practices.

> Even frameworks that make a 
> major point of having minimal impact on the global namespace actually
> introduce potential conflicts in ways that are not always easy to
> see. For example, it's common practice to have APIs that query the
> DOM and return DOM elements that are mixed-in with additional
> functionality.

Lets be VERY clear about this: toolkit vendors do this because IE does 
not allow any useful form of subclassing of DOM elements. Dojo provides 
a widget system and the NodeList classes for this very reason (we wrap 
but never extend). Other browsers have some means of DOMElement 
subclassing although they are far from ideal or coherent at this point. 
Every toolkit vendor I know would like to have this fixed, but so far 
MSFT has neither shared any data about IE.next WRT this issue (or any 
others), nor have repeated calls for a solution to this issue been 
heeded in previous IE releases. Perhaps you can press the case 

> Do you also want to prohibit that?

I'm in favor of documenting these hacks and noting the interop pitfalls. 
That said, what you're describing only happens once a node is "owned" 
by a block of code, it's not a global, de-facto and by-default behavior 
imposed on every node in the system. It is, clearly, a distinct and 
separate question from that of root object prototypes.

> I think it's a fact  
> that built-in objects will be extended because it's very useful to do
> so.

It's this body's job to set standards for interoperability, not to 
condone a race to the bottom.

> I'm sure Dojo does a much better job than we do at never adding 
> an expando to any object that it doesn't own but we chose to be very
> open about everything we had so that we can spot problems that are
> likely to be found in other libraries too.

Dojo is not (and never has been) 100% "clean". What OAA needs to do is 
to set standards that libraries need to meet. Setting them high is a 
point of leverage in getting toolkit vendors (Dojo included) to do the 
right thing. Dojo only has less work to do because we knew these 
standards were coming when we sat down to do 0.9. I actually think 
that's a great case for why we should set the standards high.

> You could take the approach of prohibiting everything but the likely
> result would probably be that toolkit vendors would just go "ok,
> fine, we won't be OpenAjax-compliant then" rather than break their
> customers' applications. I don't think that's what we're trying to
> achieve here.

Fair enough, but this one is straightforward and has known interop 
issues which aren't discoverable except at runtime in composed systems. 
It's hell to debug and easily avoidable through social pressure on 

> The goal of the registry as far as I understand it is to manage
> conflicts while allowing the flexibility that is required by existing
> art.

Yep. I think the resolution would need to be something like "we'll 
accept these 10 but not these other 5, therefore you can't claim 
to "own" them and must warn your users about them". That seems 
equitable to the state of the art.

> I think it would also be useful if the Alliance provided guidelines
> in the form of "SHOULD" recommendations such as "libraries SHOULD NOT
> extend Object.prototype or Array.prototype". Whether they should
> extend instances of DOM elements

Note the terminology here. "instances" vs. "prototypes". If root DOM 
Node prototypes were exposed sanely across browsers, I'd be advocating 
just as strongly against extensions to them. Instances are a different 
ballgame than prototypes.


> or prototypes of other objects is 
> still, I believe, a subject to debate in the community and certainly
> a common practice so if we provide recommendation here it should
> probably be to limit the number of extensions rather than prohibit
> them entirely. Let's focus on making the registry a useful tool to
> the community instead of trying to impose rules that are too
> restrictive to be followed.
> Thanks,
> Bertrand
> -----Original Message-----
> From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On
> Behalf Of Alex Russell Sent: Thursday, July 12, 2007 10:15 AM
> To: ide at openajax.org
> Subject: Re: [OpenAjaxIDE] Microsoft Ajax metadata format quick start
> guide
> On Thursday 12 July 2007 7:46 am, Jon Ferraiolo wrote:
> > Hi everyone,
> > Bertrand has sent in some emails describing the list of globals and
> > JavaScript extensions that MS Ajax uses, along with the XML format
> > used to document the runtime JavaScript used by MS Ajax. I have
> > been going through some of these documents and I found it a bit
> > hard to figure out where I could find an executive summary and some
> > examples. Here is what I found:
> >
> > Executive summary of XML metadata format:
> > *
> > http://weblogs.asp.net/bleroy/archive/2007/04/23/the-format-for-jav
> >as cript-doc-comments.aspx
> >
> > List of JavaScript globals and JavaScript extensions used by MS
> > Ajax: * http://openajax.org/pipermail/interop/2007q2/000168.html
> Ouch...that's a long list. Are we going to allow any vendor to
> "register" globals which extend root object prototypes? I had thought
> that the consensus was "no", and that they should be flagged as
> dangerous and potentially conflicting (otherwise interop is a joke).
> Regards
> --
> 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

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/d1f280b2/attachment.bin 

More information about the IDE mailing list