Do we have a sense yet regarding who supports XBL2 as in the 2007
Candidate version [CR] versus who supports the version Hixie recently
published in [Draft]?
Feedback from all (potential) implementers would be especially useful.
Thinking aloud here, perhaps [Draft] could be positioned more like
XBL1++ e.g. the XBL Note [Note] + bug fixes? (BTW, wow, didn't realize
it's been almost 10 years since that Note was published.)
-Art Barstow
[CR] http://www.w3.org/TR/2007/CR-xbl-20070316/
[Draft] http://dev.w3.org/2006/xbl2/Overview.html
[Note] http://www.w3.org/TR/2001/NOTE-xbl-20010223/
On 9/9/10 3:19 PM, ext Ian Hickson wrote:
On Thu, 9 Sep 2010, Doug Schepers wrote:
Arthur Barstow wrote (on 9/8/10 1:55 PM):
On 9/4/10 6:36 AM, ext Doug Schepers wrote:
To that end, could you provide a link to the requirements document, or
if there isn't one, could you start one?
FYI: when the Web Application Formats WG transitioned XBL2 from Last
Call WD to CR (March 2007), the transition request included the
following re requirements:
[[
5. Evidence that the document satisfies group requirements:
The spec satisfies more requirements than those defined in the
group's 10 February 2006 XBL Use Cases and Requirements document:
http://lists.w3.org/Archives/Public/public-appformats/2006Feb/att-0000/XBL-UCs-and-Reqs-2006-02-10-DRAFT.html
]]
Thanks for the pointer. But it seems that the requirements have
changed, according to Hixie, so I'd like to understand better the
motivation for the changes he made.
I didn't examine the above list in depth, but apologies if I made it sound
like the requirements had changed; they haven't. What changed is the
context in which the spec is viewed -- one in which HTML has seen a
resurgence as the recognised core platform, in which our understanding of
latency and synchronicity implications in API designs is far improved, and
in which we (or at least I) have a far more appreciation of the importance
of incremental design in specifications, to lower the initial cost of
implementations without closing doors on the features the language can
support over the long term relative to the full vision of the spec.
Some record of the implementer feedback he's received would probably
suffice.
People pointed out the above (in particular the possibilities that would
be afforded by a closer integration with with HTML and XHTML, rather than
having a separate vocabulary, and the benefits of the incremental
approach). Hyatt and I then discussed how to apply these lessons to the
XBL2 spec for an initial proposal, which is what I then edited.
HTH,
