Re: XBL2

  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,

Received on Friday, 17 September 2010 13:07:01 UTC