W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: [comment] XMLHttpRequest Object - Address Extensibility

From: Jim Ley <jim@jibbering.com>
Date: Fri, 21 Apr 2006 21:38:05 +0100
Message-ID: <000e01c66583$7e5af850$2402a8c0@Snufkin>
To: "Web APIs WG \(public\)" <public-webapi@w3.org>

"Anne van Kesteren" <annevk@opera.com>
> The new extensibility section currently contains the following text:
>
>  <p>Extensions to the <code>XMLHttpRequest</code> interface are reserved 
> for
>   future work by the Web APIs WG. WGs besides the Web APIs WG may extend 
> the
>   interface, but MUST coordinate that with the Web APIs WG. UAs MAY extend 
> the
>   interface, but MUST prefix the new members using a string specific to 
> the
>   vendor following the <var>Vendor</var><var>Member</var>  scheme.

This is very silly, the VendorMember scheme is entirely stupid, it's 
completely useless for authors, we can't do anything with it, and is much 
worse than simple invented terms that eventually get standardised.

If vendor A creates a useful member, vendor B can't then copy the interface 
as they MUST prefix it with their Vendor string, when some WG eventually 
standardises it, authors now either have to ignore all existing clients and 
just support the standardised ones, or ignore the new clients - either way 
any UA that wants the code to run will have to support the silly old methods 
too (except they can't unless they're the member that invented it)

It's also of course very wrong to render all existing implementations 
non-conformant because they include extra properties and methods which the 
WG has decided not to standardise, if you do that there's really no point 
having a conformance section.

Extension requirements similar to ECMAScript would be a much more logical 
approach.

Jim. 
Received on Friday, 21 April 2006 20:39:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT