- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Mon, 15 Jan 2007 08:38:15 -0500
- To: Ian Hickson <ian@hixie.ch>, Doug Schepers <doug.schepers@vectoreal.com>, Cameron McCormack <cam@mcc.id.au>
- Cc: public-appformats@w3.org
Cameron, Doug, Ian, On Jan 13, 2007, at 6:51 PM, ext Doug Schepers wrote: > Ian Hickson wrote: > >> By keeping these features in a separate specification, they can be >> updated independently of the XBL specification itself, enabling >> faster turnaround and a more modular approach. >> Keeping the XBL2 specification smaller is also one of our design >> goals, as we would like to allow more implementations to help XBL2 >> exit CR, and not all those implementations will necessarily >> support SVG and animations. > > I personally think this is a very sensible suggestion. There are > ups and downs to the idea of creating a separate spec, though. > You've listed the major advantages, all of which I agree with. Yes, I agree Ian's suggestion is sensible and recommend it. > Disadvantage: > * as with "profiles", there's a risk that "XBL extensions" aren't > widely implemented, decreasing the likelihood that authors can rely > on that capability Even if the extensions were included in the XBL2 spec there is no guarantee they would be [completely] implemented. > > * dramatically increases the "time to market" for that particular > technology's use of XBL I don't understand this; surely those interested in the extension could closely track the XBL2 spec's progression. > * languages must conform to and special-case for XBL, rather than > vice versa (I see this as a fair trade off, since I think that XBL > will be one of the fundamental Web technologies, and it's > reasonable for languages to have to take it into account) > > The first couple disadvantages are big ones, though. Overall I think the advantages of putting language-specific extensions in separate specs dominates. Regards, Art Barstow ---
Received on Monday, 15 January 2007 13:39:15 UTC