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

Re: [comment] XMLHttpRequest Object - Address Extensibility

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 21 Apr 2006 23:07:32 +0200
To: "Jim Ley" <jim@jibbering.com>
Cc: "Web APIs WG \(public\)" <public-webapi@w3.org>
Message-ID: <hhhi4293oh7o8gds3o6hff4h4fpqk0pgtv@hive.bjoern.hoehrmann.de>

* Jim Ley wrote:
>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.

It is very useful if it is immediately obvious that some member is a
possibly experimental and unsupported vendor-specific extension. You
correctly point out that the proposed scheme as well as any other
scheme does have downsides aswell, but the tradeoffs are to be care-
fully considered.

>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)

There are many alternate ways to enable vendor-specific extensions
to simply allowing vendors to make up new members as they like. As
an example, a 'ext' prefix could be required which W3C promises to
never use in future versions of the specification and vendors may
to in that namespace whatever they like. This would mitigate the
problem of multiple vendors adopting each others extensions. It
would also be possible to setup a first come, first serve registry
and so on.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Friday, 21 April 2006 21:07:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC