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